Eskişehir Devfest Student Etkinliği

Geçtiğimiz hafta Eskişehir Anadolu Üniversitesi'nde Devfest Student etkinliği düzenlendi. Etkinliğe ben, Aybüke, Gülşah ve Necdet hoca birlikte katıldık.

Etkinlikte Aybüke ve Gülşah Opw sürecinden bahsettiler. Ben de Ruby & Gtk3 ile masaüstü uygulamalar yazmaktan bahsettim. 3 Mayıs'ta İstanbul ve Denizli'de de başka etkinlikler düzenlediğinden katılım oldukça azdı. Etkinlikte yaptığım konuşmanın sunumuna buradan ulaşabilirsiniz.

Sunum sonrası elbette şehri gezdik :). Üst dönemlerden Serhat Ersel bize şehri gezdirdi. Serhat'ı daha önceden okuduğum eğlenceli blog yazılarından ve tweetlerinden tanıyordum, aynı zamanda Serhat da öğrenciyken Necdet hoca ile çalışıyormuş.

Eskişehir birçok heykel barındıran, hareketli bir şehir ve aynı zamanda başka şehirlerden gezmeye gelen insanlarla dolup taşıyor diyebilirim. Gerçekten de gezilip görülmesi gereken bir şehir. Şehirde bizi misafir ettiğinden Serhat'a teşekkürler.

Latex ile Belge Hazırlama

Latex, işaretleme dili kullanılarak belge ya da sunum hazırlamak için kullanılan bir araç. Latex ile yazdığımız belgeleri pdf ve birkaç değişik biçime çevirebiliriz.

Latex'i ilk 2. sınıftayken Necdet hocanın önerisi üzerine kullanmıştım :). Latex ile belge hazırlarken matematiksel ifadeleri, şekilleri çok rahat sağlayabiliriz. .tex dosyalarını terminalden parametreler vererek istediğimiz biçime çevirebileceğimiz gibi, Latex için yazılmış arayüzleri, hazır şablonları da kullanabiliriz.

Bugünlerde cv hazırlamak için Latex kullanmam gerekti. Libre Office writer ya da Google Doc'da belge hazırlarken içeriğin yerleşimi zor oluyor ve uğraştırıyor. En ufak bir satır eklediğimizde içeriğin kalan kısmının yerleşimini bozuyor, aslında bunlarla uğraşmamak için Latex kullandım.

Latex'in birçok etiketinin ne olduğunu şimdilerde pek hatırlamıyorum :). 2. sınıftan sonra unutmuşum haliyle. Bu yüzden hazırladığım belgenin hepsini elle yazmadım, hazır şablonlardan birini seçip, beğenmediğim yerleri değiştirdim.

Latex'i ilk kullandığım zamanlarda konsoldan çalıştırıyordum. Ancak bu ara pek vaktim olmadığından, bir de çıktıyı hızlı bir şekilde görebilmek için texworks editörünü kullandım. Texworks çok güzel ve kullanımı rahat bir araç. Dosyada yaptığımız değişiklikleri yanda hemen görebiliyoruz.

Latex için hazır şablonlara buradan ulaşabilirsiniz.

Muğla Özgür Yazılım Semineri - 2014

Bu yıl yine Muğla Sıtkı Koçman Üniversitesi'nde özgür yazılımlar hakkında konuşmak için gittik. İlk konuşmayı Necdet hoca yaptı. Sonrasında ben "Bilgisayar Mühendisliği Öğrencilerine Tavsiyeler" konulu bir sunum yaptım. 4 yıl boyunca karşılaştığım şeyleri ve nasıl yapsak daha iyi olacağından bahsettim.

Konuşma sırasında birkaç yeri atlamışım. Eksik kaldığını düşündüğüm yerleri ara verdiğimizde arkadaşlarla bir araya gelerek konuştum. Benim bahsetmediğim yerlerden Doruk Fişek benden sonraki sunumunda bahsetti. Atladığım alt başlıklar kendimizi geliştirmeyi sadece iş imkanı olarak görmemek, yapacağımız işte heyecanlı olmak, severek çalışmak ve birkaç şey daha. Heyecanlı olmak kısmını ise konuşurken uygulamalı bir şekilde gösterdim bence :) Sunumun slaytlarına buradan ulaşabilirsiniz.

Aybüke ve Gülşah birlikte çekirdeğe katkı sürecinden bahsetti. Aslında daha çok git kullanımından bahsettiler.

Muğla'da üç gün kaldık. Esra ve ailesi hepimizi evinde misafir etti. Hafta sonu Aydan, Simge ve Merve geldiler. Bol bol gezdik, eğlendik ve ilk vine videomuzu çekmiş olduk :). Aslında her şey Aybüke'nin kaza ördek demesiyle demesiyle başladı. "O ördek değil kaz" konulu videomuza buradan ulaşabilirsiniz.

Bu dönem çok sıkılmıştım benim için çok güzel bir etkinlik ve devamında tatil oldu. Esra'ya bizi evinde misafir ettiğinden, Necdet hoca ve Enis hocaya etkinliği düzenlediklerinden çok teşekkür ediyorum.

Bunlar da etkinlikten birkaç kare :)

Yeni Başlayanlar İçin Linux Kernel Araçları

Yorucu bir vize haftasının ardından tekrar kendimi geliştirmek için çalıştığım şeylere devam ediyorum. Aslında devam etmeye çalışıyorum çünkü gerçekten çok yorulmuşum :(. Bir de son sınıf olunca sanırım insan kendini daha çok yorulmuş hissediyor.

Linux Kernel için okuduğum şeylere devam ediyorum. Bugünlerde çekirdek geliştiricisi olmanın ne kadar güç bir şey olduğunu anlamam konusunda zirveye ulaşıyorum. Linux Kernel'a yeni başlayanlar için hazırlanan sitelerde hep bu resmin olması da bana bir işaret olabilir :)

Elbette çekirdek geliştiriciliğinin kolay bir şey olmadığının herkes gibi biliyorum. Ancak okuduğum bir yazıyı anlamak için bir kaç kere okumak, her belgenin çok uzun olması, bir çok satırda ne söylenilmek istenildiğini tam anlayamayıp on tane daha yere bakmak biraz yorucu. Bir de hatanın hangi durumlarda oluştuğunu anlayıp, o kod içerisinde oluştuğunu anlayamamak bir problem. Örneğin paylaşımlı veri yapıları ile ilgili problemleri çözebiliriz ancak o veri yapısı paylaşımlı mı nasıl anlayacağız :) gibi.

Aslında geliştiricilik olmasa bile daha güzel katkılar vermek istiyorum. Çünkü çalıştığım ilk bir ayda checkpatch.pl, sparse ve çok az coccinelle kullandım. Bunlar statik ve en temel araçlar.

checkpatch.pl ile gönderilen yamalar geliştiricilerin de okumaktan biraz sıkıldığı yamalar. Sparse ise derleme sırasında hata vermeyen ancak statik yazılım denetimi yapan ve Torvalds tarafından başlatılan bir proje. 

Coccinelle ise tüm bunlardan daha farklı. Kendine özel Smpl (Semantic Patch Languange) ile yazılan anlamsal betiklerden oluşuyor. Cocci kullanırken kendimiz bir hata tipi seçiyoruz. Bu hata tipi sparse, checkpatch.pl ya da başka bir araçla alınan ya da kendi belirlediğimiz bir hata tipi olabilir. Sparse hatalarını .cocci betikleriyle düzeltmek zor. Çünkü Sparse hatalarını çözmek için tek bir standart yok ancak checkpatch.pl öyle değil. Belirlediğimiz bu hata tipi için genelde formal diller adı altında geçen statement, expression, identifier gibi kavramlarla bir şablon oluşturuyoruz. Bu hatanın çözümü için ise yine kendimiz başka bir şablon oluşturuyoruz. Aslında betikte hem hatayı hem de çözümü bir şablon halinde belirtmiş oluyoruz.

Çalıştığım bir aylık süreçte bu üç aracı öğrendim diyebilirim. Bir de smatch var ama ben kendisini hiç kullanmadım :) Bugünlerde ise modüller için dinamik test etme araçlarına bakmaya karar verdim. Hangi araçlar olduğu ve nasıl kullanıldıkları hakkında henüz bir fikrim yok :) ama standart olarak hiç fikrimin olmadığı şeylere en baştan bakıyorum. Bir de çekirdek geliştiricileri çok yoğun olduklarından çok fazla cevap atmıyorlar listelerde ya da irc'de. Bir de sanırım bu kural gibi, sana verilen bir işi listelerde sormadan kendin yapmalısın.

Geçen gün Linux Kernel katkıcısı olmak için düzenlenen Eudyptula Challenge sürecini gördüm. Aslında ortada bir challange yok :) Kendimiz basitten karmaşığa driver yazmaya başlıyoruz. Bu süreçte de her işi kendin yapmalısın ve listelerde ya da irc'de sormayın diye kesin bir şekilde belirtmişler. Bu Opw için de geçerli miydi bilmiyorum. 

Önümüzdeki günlerde Muğla ve Eskişehir'de sunum yapacağım. Döndükten sonra Linux Kernel ile ilgili okuduğum şeylere devam etmeyi ve Sparse, Cocci kullanımının nasıl olduğunu burada yazmayı düşünüyorum.

İnternet Konferansı - 2013

9-11 Aralık'ta  İstanbul Üniversitesi'nde düzenlenen İnternet Konferansı'na katıldım. Hafta içine denk gelmesi ve derslerimin olması nedeniyle sadece son gününe katılabildim. Konferansta 2 panel dinledim. Aynı zamanda sunum yapmak için konuşmacı olarak katıldım. Etkinliğin son günü sanırım yoğun kar yağışı nedeniyle katılım oldukça azdı.

Sunumu Galatasaray Üniversite'sinden Tülin ile birlikte yaptık. Aslında Tülin ile daha önceden hiç görüşmemiştik. Geçen yıl Gnome Opw'ye katıldığından listede e-postalarını görüyordum. Tülin geçen yaz Opw'de Linux çekirdeği projesinde staj yaptı.

Konferansta "Linux Çekirdeğine Nasıl Katkı Verilir?" başlığı altında sunum yaptık. Tülin ile birlikte sunum yapmayı Necdet hoca önermişti, bizde kabul ettik :) Sunuma birlikte hazırlanma fırsatımız olmadı. İnternet üzerinden bir kaç kez görüşüp değineceğimiz yerleri belirledik.

Sunumda anlattıklarımızı bildiri olarak yayınladık. Bildiriye buradan ulaşabilirsiniz. Aynı zamanda diğer sunumların bildirilerine buradan bakabilirsiniz.

LPI 102 Sınavı

Bu yılın başlarında Lpi 101 sınavına girip geçmiştim. Dün Lpi 102 sınavına girdik. Bence sınav hiç kolay değildi :) Aslında kolay olmadığını düşünmemde geçen yıla göre az çalışmış olmamın da etkisi var. Geçen yıl bölümden sınava katılan arkadaşlarımla bir sınıfta toplanıp, konulara hepimiz hazırlanıp sonra her hafta bir kişinin o konuyu bize sunmasıyla ilerlemişti. Necdet hoca konuyu anlattığımız sınıfta olup, onun da ek bir şeyler anlatmasıyla konular ilerliyordu. Lpi 102'de böyle yapamadık malesef. Topluca çalışmadık, bireysel hazırlandık. Biz 102 sınavına girerken, 101'e girmemiş olan arkadaşlardan da 101 sınavına katılanlar oldu. Sınava hazırlanma sürecinde en çok X yapılandırmasından ve yönetimsel görevler konusundan (kullanıcı ekleme, silme, grupları yönetme) çok sıkıldım :) Bu yüzden ilk ağ yapılandırması konusundan çalışmaya başladım.

Geçen yıl örnek soru çözmeye çok vakit bulamamıştım. Aslında örnek soru derken Lpi sınav sorularını,sınava girdikten sonra herhangi bir yerde paylaşmak ve çoğaltmak yasak. Ama Lpi konularını içeren sorular hazırlanmış o soruları çözdüm. Çünkü çok fazla komut oluyor ve parametreleri akılda tutmak örnek soruyla daha rahat olabiliyor. Ya da eğer bir komutun tam ne işe yaradığını anlamadıysak soruda görmemiz yardımcı olabiliyor. Bunun için aşağıda linkini verdiğim sitelere baktım. Aslında bu siteleri Tuğçe önerdi, Tuğçe sınıf arkadaşım. Bir de son gece buraya baktım, buradaki bazı sorular kolay ama bazıları gerçekten zor :) Bir de konu dağılımındaki ağırlıklar nasıl diye merak edenler için burası var.

[1] http://www.penguintutor.com/quiz/
[2] http://www.gocertify.com/quizzes/linux-practice-questions/linux-lpi102-lx0102-quiz.html

Bu yıl sınava daha az hazırlanma fırsatı bulmamla birlikte geçersem Lpi 201'e daha fazla çalışacağımı düşünüyorum.

Aslında sertifika almak her şey değil tabi, neticede insan 3 ay sonra bile sınava çalıştığı zamanki kadar ayrıntılı hatırlayamaz her şeyi. Ancak Linux üzerinde çalışırken nelerin daha fazla yapılabildiğini bilmek (ne gibi araçların olduğunu anımsamak) proje geliştirmeyi kolaylaştırır. Eğer sadece neler yapılabiliyor Linux'ta diye açıp bir kitaba baksam muhtemelen baktıktan sonra hatırlayacaklarım bir sınava hazırlandıktan sonra hatırlayacaklarımdan oldukça az olacak. Linux'a olan bakış açımı geliştirdiğini düşündüğümden Lpi konularına çalışmayı seviyorum.

Watchdog İle Bildirim Alma

Bu yıl bitirme projemin bir kısmında watchdog kullandım. Watchdog ile makinemizde meydana gelen çeşitli değişiklikleri izleyebiliriz. Ben sadece dosyalar üzerindeki değişiklikleri izlemek için Pyhon modülünü kullandım.

Benim düşüncem Watchdog'un kullanıma hazır denilebilmesi için eksikleri var. Çünkü dosyalar üzerindeki değişiklikleri izleme işlemini Watchdog'u başka bir yazılım ile bütünleştirerek yapmak çok sağlıklı değil. Örneğin, eğer var olan bir dosyayı değiştiriyorsak o dosya için sırasıyla "Silindi, Oluşturuldu, Değiştirildi" bilgisini döndürüyor  (editörden bağımsız olarak) . Oysa tek döndürmesi gereken bilgi "Değiştirildi" olmalı. Aynı zamanda dosya taşıma işleminde, eğer izlemediğimiz bir yerden dosyayı izlediğimiz alana taşıyorsak "Oluşturuldu" ya da "Taşındı" bilgisini döndüremiyor. 

Burada Watchdog için istenen özellikler, hatalar listelenmiş. Belki dönem içerisinde bende kaynak kodu incelerim. Benim yukarıda bahsettiğim eksikliklerin bir kısmı için Github'a yama gönderilmiş. Ancak ben yamaları koda eklediğimde doğru çalışmadı.

Bu yılki projemde Watchdog'u kullanmam dışında, Necdet hoca "/etc"yi izleyip orada meydana gelen değişiklikleri e-posta gönderen bir betik yazmamı istedi. Bunun için yazdığım kodda oldukça kısa. Buradan ulaşabilirsiniz.

Özgür Web Teknolojileri Günleri 2013

Geçen hafta sonu Yeditepe Üniversitesi'nde Özgür Web Teknolojileri Günleri etkinliği yapıldı. Çömü'den Necdet hoca ve Aybüke ile katıldık. Bu yıl etkinlik sınav zamanına denk geldiğinden bizim üniversiteden sadece Aybüke ve ben katılabildik. 1. ve 3. sınıfların sınavları hafta sonuna kadar sürdü. Tabi Çömü'lü mezunlardan da bir sürü gelen vardı :)

Bu yıl genel konu "Ölçeklenebilirlik" üzerineydi. Aybüke ve ben aynı zamanda konuşmacı olarak katılmıştık. Ben geçen dönem Kaan ile çalıştığım projeden, Nagios, Couchbase, eklenti yazımı gibi konulardan bahsettim. Aybüke yazın stajı Kaan'ın yanında yaptı. Staj sırasında yazdığı haproxy-tools'dan bahsetti.

Bu yaptığım 2. konuşma olması ile birlikte bu sefer daha fazla heyecanlandım. İlki Muğla'daydı. Orada genelde dinleyiciler öğrencilerden oluştuğu için daha rahattım, çünkü ben de öğrenciyim. Sunum öncesi Doruk Fişek tavsiyelerde bulundu ama sunumu izlediğimde fark ettim ki, pek uygulamamışım :) Bir sonraki sunumumda muhtemelen daha rahat konuşurum diye düşünüyorum.

Dinlediğim sunumlardan en çok Gökhan'ın konuşmasını beğendim. Sunum başlığı "Ölçeklenebilir Web Mimarisi"ydi. Gökhan, Çömü'den mezun. Ben 1. sınıftayken, o 4. sınıftı ve ÇOMaK projesinde çalışıyordu. Sunumda oldukça güzel ve eğlenceli anlattı.

Etkinliğin 2. günü mezun olan üst dönemlerle toplanıp, görüşme fırsatım oldu. Ben çalışma hayatıyla ilgili merak ettiklerimi sordum. Mezuniyet sonrası için düşüncelerim biraz değişti. Aslında bu dönem başında Necdet hoca mezuniyet sonrası için aynı şeyleri önermişti.

Son olarak etkinlik hediyesi tişörtü çok beğendim :)

Linux Çekirdeğine Nasıl Katkı Verilir?

Gnome'un düzenlemiş olduğu Outreach for Women etkinliğine başvuru süreci 11 Kasım'da bitiyor. Ben bu süreçte Linux Kernel için hazırlandım. Geçen yıl Gnome'un kendi araçlarına başvuruyordum ama sürekli bir şeyler derlemek, kütüphane sürümlerini uyuşturmaya çalışmak bir miktar sıkıcı olabiliyor. Bunun için jhbuild ya da Fedora'nın bir sonraki, henüz çıkmamış sürümünü kullanmak tavsiye ediliyor :) Çünkü katkı vereceğimiz Gnome aracının depodaki son hali üzerine değişiklik yapmalıyız. Çekirdek üzerinde çalışmanın nasıl olduğunu bilmediğimden bu sefer çekirdeğe başvurmaya karar verdim.

Opw Kernel sayfasında tüm yapılması gerekenler, okumak için önerilen bir kaç kitap var. Öncelikle örnek olarak ethernet kodu içine printk("..") ile bir şeyler yazdırıp, çıktısını dmesg logunda görmek var. Burada Greg Kroah-Hartman ilk yamanın nasıl yapılacağından bahsetmiş. Temel olarak yama göndermeye kernel.org'dan aldığımız çekirdek kodları dizini içerisindeki drivers/staging'den başlayabiliriz. Buradaki kodların yazılış biçimini düzeltmeyle işe başlayabiliriz. Greg'de linkini verdiğim sunumunda bundan bahsetmiş. Çok temel kodlama biçimi düzeltmeleri yapabileceğimiz gibi, daha karma düzeltmeler de yapabiliriz. Bir de yama gönderirken e-posta konu satırına uyarı çıktısının tam halini yazmamız gerekiyor. Kendimiz uyarıyı yorumlayıp "bu yama bunu düzeltiyor" şeklinde yazdıklarımız genelde kabul edilmeyebiliyor. Bu yüzden tekrar göndermemiz gerekiyor.

Opw Kernel'a başvurmak için bu temel yamalardan göndermek yeterli. Hatta bu yılki Opw projelerinden birisi de kodlama biçimi düzeltme ve Todo dosyalarındaki eksikleri kapatma. Todo dosyalarındaki eksikleri kapatmak biraz daha alt seviye, aslında baya bir alt seviye :). Çünkü yapılması istenenler de o kadar açık belirtilmemiş dosyada. Ben de çekirdek uyarı mesajlarını analiz etme ve iyileştirme projesine başvurdum.

Başlangıç olarak Linux Kernel'a kodlama biçimi düzeltme dışında Sparse ve Coccinelle araçlarını kullanarak katkı verebiliriz. Bu araçlarla drivers/staging altındaki kodları derlediğimizde aldığımız uyarı mesajlarına göre düzeltmeler yapabiliriz. Bir de kodlar içerisinde yer alan Fixme etiketlerinden yararlanarak katkı vermek de yapabileceğimiz seçeneklerden birisi. Katkı verirken zorlanabileceğimiz yanlardan birisi, Linux Kernel ekibi kodlama biçimine oldukça önem veriyor. Bu yüzden aynı yamayı defalarca göndermek gerekebiliyor. Hatta kodlama biçimini test etmek için yazdıkları bir Perl betiği var. Zaten kodlama biçimi düzeltme yamalarını gönderebilmek için bu betiği kullanmalıyız.

Sparse aracı ile fonksiyon tiplerinin ya da değişken tiplerinin doğruluğu, gereksiz fonksiyonları kaldırma, tip dönüşüm işlemlerinin doğruluğu gibi uyarıları analiz edebiliriz. Bu düzeltmeleri yapmak için koddaki fonksiyonları okuyup, çağırılma sıralarını kontrol etmek, kzallac, kmalloc, volatile gibi tiplere, tip dönüşümlerine bakmak gerekli. Çeşitli tiplerin ne olduğunu öğrenmek için burayı okumak faydalı olabilir.

Coccinelle aracını ise ben henüz kullanmadım. Ancak önümüzdeki günlerde onu da denemeyi düşünüyorum. Bir de daha karmaşık hataları çözebilmek için bir kitap bulup okumayı düşünüyorum.

Opw ekibi projede çalışmak için kişi seçerken genelde öğrenci olmamasını tercih ediyor :( . Okul dönemi içerisinde olan bir öğrenci seçmektense herhangi bir işte çalışmayan birisini seçmenin daha verimli olacağı düşüncesindeler. Bu yüzden öğrencilerin Opw yaz dönemine başvurunca seçilme ihtimali daha yüksek. Çünkü proje sürecinde bir işin var mı sorusuna, sınav haftalarını yazmaktansa hiç işim yok yazmak, şansımızı artıran bir etken. Eğer ben de bu dönem kabul edilmezsem, yaz dönemi tekrar başvuracağım.

Çekirdeğe Katkı Sürecinde Git Kullanımı

Git uzaktan birlikte çalışmak için oldukça yetenekli bir araç. Bu dönem Linux Kernel'a katkı verirken git'in daha fazla özelliğini kullanmam gerekti. Çünkü çok fazla kişinin sürekli aynı dosyalar üzerinde değişiklik yapıyor olması durumunda daha gelişmiş bir biçimde sürüm takip sistemi kullanmak gerekiyor.

git-send-mail

Tarayıcı üzerinden yamayı mail gövdesine kopyaladığımızda girintilerde kaymalar, satırlarda kaymalar meydana gelebilir. Bunun için yama dosyasını e-postada ek olarak göndermeliyiz, ya da git-send-mail ile göndermeliyiz. git-send-mail için temel bir kaç ayar gerekli, bu ayarları her seferinde yeniden girmemek için yapılandırma dosyasına yazabiliriz. Ev dizinimizdeki .gitconfig dosyası için gerekli olan ayarları ben buradan örnek alarak ayarlamıştım

git-rebase

Yerelimdeki Linux Kernel deposuyla uzaktaki depoyu senkron tutmam gerekti. Opw Kernel sayfasında bahsedildiği gibi depomda değişiklikler yaptım. Bunun için öncelikle "git remote add" diyerek "staging" adı altında depoyu izlediğim depolar arasına ekledim. Bu şekilde depo ekleyip, deponun istediğimiz dallarını çekebiliriz. Daha sonra "git rebase staging/staging-next" ile rebase işlemini tamamlamış oluyoruz.

Aslında burada aklıma takılan "merge" kullanarak da bir çok şeyi halledemez miyiz, olmuştu. Ancak merge kullandığımızda aynı depo üzerinde çalışan herkesin, her şeyi kusursuz yapmış olmasını beklemek gerekir. Eğer küçük bir ekiple çalışıyorsak "merge" yeterli oluyor. 

git-rebase ile aynı zamanda commit tarihimizi değiştirebiliriz, eskiden yaptığımız bir committeki değişiklikleri düzenleyebiliriz. Bunun için "git rebase --interacative commit_id" diyoruz. Bu şekilde rebase etme sürecini başlatabiliriz.

Eğer son yaptığımız committe bir değişiklik yapacaksak "git commit --amend" olarak kullanabiliriz, ancak son committen daha eski commitler üzerinde oynamak için "git rebase --interactive" kullanmalıyız. Daha sonra karşımıza çıkan editörde commit mesajını değiştirmek istediğimiz commitin başındaki "pick" ifadesini "edit" olarak değiştirmeliyiz. Daha sonra "git commit --amend" kullanıp, commit mesajını değiştirmeye başlayabiliriz. Son olarak "git rebase --continue" ile commit mesajı değiştirme sürecini bitirmiş oluruz.

Üzerinde oynadığım büyük bir dosyada 9 tane commit yapmıştım ve bu commitlerde yaptığım değişikliklerin arasından 4-5 tanesini düzeltmem gerekti. Son değişikliklerde öncekilere bağlı olduğundan, dosyanın son hali üzerinden tekrar düzeltip göndersem, dosyanın depodaki orjinali bu değil diye geliştiriciler kabul etmiyorlar. Bu durumda eğer 5. commit değişmeliyse, dosyanın 5. committeki hali üzerinden düzeltmek gerekli. Ya da tüm yama serisini baştan hazırlamalıyız ki, bu zorlaştıran bir iş.

Bu yüzden git rebase'i kullanıp, edit şeklinde committi seçiyoruz. Daha sonra değişiklikleri yapıp "git add üzerinde_çalıştığımız_dosya" ve "git rebase --continue" şeklinde bu işlemi bitirebiliriz. "--continue" parametresini rebase ile yapacağımız değişiklikler bittikten sonra kullanmalıyız.

edit, dışında bir de "squash" ile yaptığımız commitleri birleştirebiliriz. Eğer altı kere değişiklik yapıp bunları hepsini ayrı ayrı commitlediysek format-patch ile oluşturacağımız yamalarda altı parçadan oluşacak. Eğer bunların hepsini tek bir commit mesajı altında birleştirmek istiyorsak "pick" yerine "squash" yazarak bir kaç commit mesajını bir mesajda birleştirmeyi sağlayabiliriz.

Kadın Geliştiriciler İçin Gnome Etkinliği

Gnome'un kadınlar için düzenlediği Outreach Program for Women (OPW) etkinlik süreci yaklaşıyor. Bu etkinlik yılda iki kez düzenleniyor. Her hangi bir akademik kısıtlaması olmamakla birlikte 18 yaşından büyük kadınlar katılabilir. Bu etkinlik GSOC gibi, belirli bir süre, bir danışman yardımı ile uzaktan çalışma gerçekleştiriliyor. Eğer projeyi başarılı bir şekilde tamamlarsak karşılığında $5,000 dolar gibi bir burs da alabiliriz.

OPW 2013 yaz döneminde ise Linux Kernel Gnome'un düzenlediği bu etkinliğe katılmaya başladı. Linux Kernel'a katkı vermeye yeni başlayanlar için güzel bir yazı hazırlamışlar. 2013 yaz dönemi Linux Kernel için çok az bakabilme fırsatı bulduğumdan yama gönderemedim. Bu etkinlikler genel olarak sınav dönemine çok yakın bir zamana denk geliyor :) Diğer projelerle birlikte bu etkinliklere katılmak biraz zor olabiliyor. Eğer bu yıl katılırsam Linux Kernel'a kaldığım yerden devam ederim muhtemelen.

Aslında geçen yıl kış dönemi etkinliğine projelere katkı verip katılmıştım. Ancak seçtiğim proje OPW tarafından geliştirilmek için seçilmedi. Yaz döneminde ise çekirdekle ilgili projeler görünce, o daha çok ilgimi çektiğinden ona katkı vermek istedim.

Gnome'un bu staj etkinliğine GSOC kadar geniş ölçüde organizasyon katılmıyor. Bu yüzden proje seçmek için daha az bir alan var. Etkinliğe katılan organizasyonları görmek için buraya bakabilirsiniz.

Yakından Eğitim Projem Nagios Exchange'de Yer Aldı

Nagios Exchange Nagios için yazılan belgeler, eklentiler, Nagios ile birlikte çalışan uygulamaların yer aldığı resmi sistesi. Kaan ile birlikte üzerinde çalıştığım Yakından Eğitim projesi olan nagios-couchbase-plugin'in Nagios Exchange'de yer alması için dün istekte bulundum ve bugün Nagios Exchange'den proje kabul edildi maili aldım :)

 Eklenti eğer resmi sayfada yer alırsa daha çok kullanılır ve daha yararlı olur diye düşündüm. Projenin linkine buradan ulaşabilirsiniz.

Chef Server'ın Oluştuğu Bileşenler

Chef Server'da cookbookları depolayabiliriz demiştik, her  cookbook'un kendi içeriğindeki dosyalara göre de sunucuları yapılandırabiliriz. Chef istemcileri de Chef sunucusundan nasıl davranması gerektiği bilgisini alır ve ona göre sunucuyu yapılandırır. Chef Server Erlang kullanılarak yazılmıştır ve Chef Server'ın sağladığı hizmetler aşağıdaki bileşenlerle sağlanır:

Bookshelf: Bookshelf ile cookbook dosyalarının depolanması ve workstationdaki cookbookların Chef sunucusuna gönderilmesi sağlanır. Eğer farklı cookbooklar aynı dosyayı içeriyorsa ya da aynı cookbookun farklı sürümlerinde aynı dosyalar varsa Bookshelf bu dosyaları sadece bir kez depolar.

WebUI: Ruby on Rails ile kodlanmış, Chef Server için bir arayüzdür.

Erchef (Erlang API Server): Chef Server için bir API'dir. Bu API hala orjinal Ruby tabanlı Chef Server için uyumludur.

Mesaj Kuyruğu: Mesajlar search indexlerine gönderilirler. RabbitMQ Chef Server'da mesaj kuyruğu olarak için kullanılır.

Nginx: Chef Server için yük dengeleyici (front end load balancer) olarak kullanılan bir sunucudur. Chef Server Api'sine gelen tüm istekler Nginx sayesinde yönlendirilirler.

PostgreSQL: Verileri tutmak için kullanılan depodur.

Chef Server'da Knife Kullanımı

Geçen hafta Chef Server kullanımı, cookbook kavramı, cookbookların içerdikleri dosyalar, cookbook kullanma gereksinimi gibi kavramlara baktım. Stajın 4. gününden sonra baya bir hastalandım. Bu sefer midem değil ama ofis biraz serindi sanırım ondan kusma, ateşlenme meydana geldi. Bir kaç gün izin aldım Kaanlardan.

Bu haftada knife ile Chef istemcisi oluşturma, data bag, roller gibi kavramlara baktım. Burada Chef sunucusunu knife eklentisi kullanarak yönetmeden bahsetmiş. İlk önce kendi makinem üzerinde vagrant ile bir sanal makine açıp onun Amazon'daki Chef sunucumuz için bir istemci olmasını sağladık.

Oluşturduğumuz istemci üzerinde bir kaç cookbook çalıştırmak için workstation üzerinde roller tanımladım. Kullanmak istediğimiz cookbook'u "knife cookbook site install cookbook_name" şeklinde workstationdaki Chef deposuna (chef dizini) indirebiliriz. Daha sonra chef/roles içine çalıştırmak istediğimiz cookbooklar içindeki recipe'leri run_list'e ekliyoruz. Bu şekilde istediğimiz kadar istemciye istediğimiz şeyleri tek seferde yaptırabiliriz. İndirdiğimiz cookbookları aynı zamanda Chef sunucumuza "knife cookbook upload --all" şeklinde göndermeliyiz. Yoksa istemci üzerinde cookbookları çalıştıramayız. Eklediğimiz rolü de yüklemeliyiz. Bunu da "knife role from file roles/role.rb" şeklinde yapabiliriz.

Data Bag

Data bag kavramı Chef istemcilerinde kullanıcı oluşturmak için kullanılan, json şeklinde depolanan dosyalardır. users cookbook'u eğer kullanıcılar data bag'de varsa, o kullanıcıları istediğimiz özelliklerde istediğimiz makineye eklememizi sağlar. Burada data bag'e kullanıcı ekleme işleminin nasıl yapılacağından ve json dosyasının nasıl yazılması gerektiğinden bahsetmiş. Workstation'daki chef/databags/users dizini altında istediğimiz kullanıcıları tanımlayıp, "knife data bag from file kaan.json" şeklinde kullanıcıyı data bag'e ekleyebiliriz.

Environment

Her Chef organizasyonunun varsayılan ortamı (environment)  _default'tur. Environment kavramı ortamları ayırmak için kullanılır. Workstationdaki chef/environments dizini altına tanımladığımız ortamın özelliklerini (cookbook sürümleri gibi) environment_name.json şeklinde kaydedip gene knife kullanarak istediğimiz istemci için bu ortamı kullanabiliriz.

LWRPs

LWRPs (Lightweight resources and recipes) Chef'te paket yükleme, servis başlatma gibi işlemler için kullanılır. Benim de sunucular üzerinde işlem yaptırırken kendim bu gibi işlemleri tanımlamam gerekecek. 

Vagrant, Chef Solo, Chef Server ile Sunucu Yönetimi

Bu yaz stajı 2 sistem yöneticisinin yanında yapıyorum. Öğreneceğim teknolojiler de gene sunucu bakımı, yönetimi üzerine olacak. Şuan çok fazla bilmediğim kavram olduğu için bir süreyi kavramları öğrenmeye, temel bir kaç deneme yapmaya ayırdık. Kullanmam gereken şeyler arasında tek bildiğim şey Ruby, kullanacağım diğer her şeyi ben de daha önce kullanmadım. Zaten on tane makine açayım onları yapılandıran betikler yazayım gibi bir düşüncesi olmuyor insanın durup dururken :)

Dün Kaan kendi kullandıkları teknolojilerden bahsetti. Yeni duyduğum, öğrendiğim şeyler karşısında verdiğim standart tepki olarak "insanlar biliyorlar, insanlar yapıyorlar" oldu :)

Çalışmaya önce Vagrant ile başladım. Vagrant sanal makine açarken istediğimiz özellikleri daha rahat verebildiğimiz bir araç. Örneğin ram ayarlarını bir Vagrantfile içerisinden makineyi ilk oluştururken yapabiliyoruz. Komut satırından yönetim yaptığımız için hızlı.

 Chef solo kullanımı ilk Vagrantfile içerisinden yaptım. Vagrantfile içerisinden çalıştırılması gereken cookbookları tanımlayabiliyoruz. Bu şekilde Chef sunucusu, Chef istemcisi gibi konulara bakmadan temel bir cookbook çalışmasını ve dosyalarını inceleyebiliriz. Cookbooklar ise Chef'teki makinelerin nasıl çalışacağının adımları tanımlayan dosyalardan oluşuyor. Biraz Couchbase cookbookunun kodunu incelemiştim. Burada temel bir cookbook yapmışlar. Çalıştırıp denemedim henüz ama belgesinde Couchbase kurulumu ve yapılandırması sağladığı yazıyor, ama Couchbase'de yapılan diğer işlere destek vermiyor. Cookbooklar da temel olarak aşağıdaki işlemler sağlanabiliyor:

1) Düğüm (node) üzerindeki temel ayarlar
2) Dosya dağılımları
3) Versiyon kısıtlamaları, desteklediği platformlar
4) Recipes dizini içerisindeki dosyaların hangi tarife göre çalıştırılacağı

Cookbooklarda karşımıza çıkan kavramlardan kaynaklar (resources) ve sağlayıcı (provider) ise şu şekilde: Kaynaklar, Chef farklı görevler için çalışırken (paket yükleme, dosya sistemine erişme, servis çalışabilir durumda mı, hangi kullanıcı, hangi grup için, dosyaların nereye kopyalanacağı gibi) hangi sağlayıcının kullanılacağını söyler. Çünkü her kaynak bir sağlayıcı ile ilişkilendirilmiştir. Sağlayıcı ise bu çalışma işlemlerini sağlar. Yani sağlayıcı, kaynaktaki adımları tanımlar. Örneğin paket yüklemesinde "apt_package" kaynağı apt kullanan sistemler için yükleme yapar, bu kaynağın yapabileceği işlemler ise install, remove, upgrade gibi "action" kavramı olarak tanımlı. Bu temel örnekteki gibi cookbooklar içerisinde istediğimiz işlemleri sırayla işletebiliriz.

Chef ise sunucuları yerleştirmeyi yönetmeyi sağlayan bir alt yapıdır ve bu yönetim cookbooklar ile sağlanır. Her makinenin kendi platformuna uygun ve isteniyorsa aynı özelliklere sahip olması sağlanır. Chef'te kullanılan kavramlar ise sunucu, çalışma alanı, ve düğümler.

Çalışma alanı denilen kavram cookbookların konumudur. Ve her düğüm ihtiyaçlarına göre bir Chef istemcisi içerir.

Son olarak knifedan da bahsedeyim. Knife, Chef üzerinde işlem yapmak için kullanılan bir araç. Chef sunucusu kurulumunu ve kullanımını kolaylaştırıyor. Ben ilk olarak Chef'i depodan indirip yapılandırmak istedim, ancak İşbaran karşı çıktı, ben biraz direndim, derken knife ile kurulum sağladık. Çünkü knife ile kurulum gerçekten daha kolay oluyormuş. Bize kurulum sırasında çeşitli seçenekler sunuyor, ve dosyaları gerekli yerlere kendisi kopyalıyor.