25 Kasım 2014 Salı

Linux Kernel Internship

Last month I've applied Gnome Outreach Program for Women and sent patches for Linux Kernel. I've applied it because wanted to learn low level things. I also really like computer design and architecture topics. Actually, I have not enough knowledge about them but like to learn them.

Linux Kernel Community accepted to me as an intern. I'll study on Khugepaged swap readahead project. Working with Linux Kernel team will be great experience for me. They really want to help kernel newbies :).

Actually, studying on Linux Kernel needs a lot reading. Just for writing a few code lines needs to read one chapter from one book, a few blog posts about topic and ask something to developers :).

Nowadays, I've started to read about memory management issues like TLB, Huge Pages, Page Fault from one operating system book and also examine do_page_fault() function.

22 Kasım 2014 Cumartesi

Google Hiring Process

This story started 4 months ago. I've got an email from a Google recruiter. She wanted to do a phone conversation with me. I was very happy to hear this and accepted the conversation immediately.

First phone conversation was initial phone interview, she asked me basic questions about data structures, bitwise operations, linux commands etc. But I think the questions were not basic :p I passed initial phone interview and preferred Site Reliability System Engineer position for myself. I took first round telephone interview with an Google engineer and used Google Doc for coding questions.

Before the first round to prepare myself I was studying algorithms, data structures, network, linux commands, troubleshooting. Following links were really helpful for me:

Geeks For GeeksGlassadorCareerupCracking Code InterviewsSystem DesignDevops Interview Questions.

I passed first round, the engineer said to me you did great most of this interview! I was really happy to hear this and couldn't believe what I heard :) The whole process was very excited, funny and nice for me.

We moved the process for second phone interview. Again I studied for same things and used Google Doc for coding questions. My second interview has only one question, when I replied the question, interviewer generated new questions which was derived from same question. Second round interview was not very good but my recruiter called me and said you passed it, we would like to invite you for onsite interview at one Google office, Google will pay your all expenses. I preferred Dublin office of Google which is headquarters for the Europe offices.

I prepared to practising English myself, and whole summer went English speaking courses, because in my country have no other chance to practising English unfortunately :(

Actually, my English is not very good and when talked with employees of Google I feel really excited so I couldn't talk much so many times :) however during the onsite interviews I discussed a lot on questions because it is my job, but for usual questions how are you?, are you excited?, do you have question? etc. this kind of questions I could talk less :) Engineers of Google are very understanding people to my English. Also in Google Dublin office, people coming from 65 different countries and there are 45 different languages.

Onsite interview have 5 different steps. For SRE (Site Reliability Engineer) position, I've got following steps and each step has 45 minutes with 5 different interviewers. Onsite interview is last round for Google hiring process.

1) ​​Non Abstract Large System Design
2) Troubleshooting / Problem Solving
3) ​Practical Coding - ​Ruby​
4) ​Design/Coding
5) Unix/ Linux ​Systems​

Onsite interview questions were not expected things for me :(. I read a lot of blog posts, they say the questions are very expected, but I think some of them really expected things however most of them were not. I also solved a lot of onsite interview questions before mine.

I couldn't pass the onsite interview however this was really great experience for me. The whole process was very exciting, every steps made me very happy and excited :).  I also met a few Google engineers and my recruiters. They are really helpful and friendly people.

Dublin is not big city so there is no a lot of people, it is not crowded. It was very rainy on my interview day. I stayed two nights in Dublin. After my interview I had time to discover the city. There is river which called as River Liffey in Dublin. It is like a map to find your road :p You can follow along the river so can find your hotel very quickly :).

I'm very happy to met with Google engineers. This was very good experience for me. I'm only 22 years old I can retry it, thanks a lot to Google.

14 Temmuz 2014 Pazartesi

Android Cihazlarda Rom Değiştirmek

Androidli telefonlarda yüklü olarak gelen rom dışında istediğimiz başka romları kurmak da mümkün. En bilinen romlar ise cynmod, miyui, aokp, paranoid android. Rom chip üzerindeki kalıcı yazılımları oluşturur. Romu değiştirerek cihazın içeriğini baştan sonra değiştirmiş olabiliriz. Bu değişim işlemci ve bellek kullanımı, kısayolları, ekran kilidi gibi birçok özelliği değiştirebilir. Telefondan aldığımız verimi artırabilir azaltabilir.

Ben şimdiye kadar cynmod'u denedim. Cihazınıza uygun cynmod romlarını buradan bulabilirsiniz. Uygun .zip dosyasını indirdikten sonra telefona sdcard içerisine kopyalamalıyız. adb reboot recovery diyerek telefonu recovery modda açıp zip dosyası kurmayı seçerek .zip'in konumunu da belirtmeliyiz. Cynmod'u kurduktan sonra Google Play Store sistemden kalkıyor. Play Store'u kurmak için gapps paketini indirmeliyiz. Gapps paketini de telefona kopyalayıp yine recovery moddan açarak kurulumu gerçekleştirmeliyiz.

Cihazın kendi sahipleri dışında bir firmanın yayınladığı romlara custom rom deniliyor. Cihaza kurulabilecek resmi (offical) romlara ise stock rom deniliyor. Custom rom kurduktan sonra stock romu indirerek tekrar cihazı ilk günkü haline çevirebiliriz.

Genelde stock romların içerisinde bir kurulum betiği oluyor. Nexus cihazlar için stock romlara buradan ulaşabilirsiniz. Nexus-5 için hammerhead .tgz dosyası içerisinde flash-all.sh dosyası var. İndridiğimiz .tgz dosyasını bilgisayarda açmalıyız. Cihazı ise adb reboot bootloader şeklinde fastboot modundan açarak bu dosyayı bilgisayardan çalıştırıp kurulumu gerçekleştirebiliriz.

13 Temmuz 2014 Pazar

Android Cihaz Rootlamak

Android telefonlara birkaç farklı şekilde root (yetkili kullanıcı) hakları verebiliriz. Android cihazlarda root olmak ise unix temelli işletim sistemlerindeki süper kullanıcı ile aynı şey.

Telefonu farklı modlarda başlatabilmek için güç, ses kısma-açma gibi tuşlara farklı kombinasyonlarda basmamız gerekli. Bu kombinasyonlar telefonun marka-modeline göre değişebilir ve elimizi sürekli şöyle miydi, böyle miydi düşüncesiyle basılı tutmak biraz zor :). Bunun yerine "android-tools-adb" ve "android-tools-fastboot" paketlerini kurarak telefonu bilgisayardan yönetebiliriz.

Android cihazlara root hakları vermek marka-modele göre değişebilir. Bu konudaki araştırmaları telefonun marka-modeline göre yapmak daha iyi olabilir. Ben burada adb ile kurulumdan bahsedeceğim için modele göre pek değişeceğini sanmıyorum ancak söylemek gerekirse Nexus-5 cihaz üzerinde çalışıyorum.

Usb kabloyu bilgisayara usb debug modda ve geliştirici hakları ile bağlamalıyız. Geliştirici yetkisi root ile aynı şey değil. Bilgisayardan telefona gelecek dosyaları kabul ettiğimizi belirtmek gibi birkaç işlem için gerekli. Geliştirici haklarına "Ayarlar->Telefon Hakkında->" yolunu izleyip "İnşa Numarası"na 5-6 kere basarak elde edilir. Debug mod için ise "Ayarlar->Geliştirici Seçenekleri"nde usb debug modunu aktif etmeliyiz.

Adb ise bilgisayardan telefonu yönetmek için gerekli. Bilgisayarda "adb devices" yazarak makineye bağlı cihazları görebiliriz. "adb shell" ile telefona bağlanabiliriz. Makineye birkaç telefon bağlı ise hangi cihaza erişeceğimizi belirtmeliyiz. "adb shell" ile telefona eriştikten sonra bash komutları ile telefonu yönetebiliriz ancak kullanabildiğimiz komutlar çok kısıtlı. Komut çeşidini artırmak için telefona busybox'ı kurabiliriz (busybox kurulumu root haklarını gerektiriyor). adb pull ile dosyaları bilgisayara çekebilir, adb push ile telefondan bilgisayara dosya aktarabiliriz. Örneğin telefondaki data dizininin içerisini root hakları olmadan listeyemeyiz, adb ile telefona bağlıyken su yazarak komut satırında root yetkilerini alabiliriz. Adb'nin tam belgesine buradan ulaşabilirsiniz.

Fastboot ise telefonu güncellemek, farklı recovery .img dosyaları yüklemek, bootloaderı kiltleyip açmak için kullanılabilir. Fastbooot hakkında daha fazlası için buraya bakabilirsiniz.

Cwm Yükleme

Telefonda yedekleme yapma, bilgileri sıfırlama, kurulum yapma gibi işlemler için birkaç farklı araç var. Bunlardan biri Clock Work Recovery Mod (cwm). Cwm'yi kurmak için buradan bilgisayara .img dosyasını indirebiliriz. adb reboot bootloader ile telefonu fastboot modunda açarak fastboot flash recovery cwm.img şeklinde recovery modu kurmuş oluruz. Şuan cihaz fastboot modda olduğu için ses kısma tuşu ile recovery moda geçerek telefonu yeniden başlatmalıyız. Böylece cwm'yi recovery mod aracı olarak yüklemiş olduk.

Root Hakları Verme

Buradan superSu.zip dosyasını telefona kopyalayıp, telefonu adb reboot recovery şeklinde recovery modda açarak install from zip'i seçmeliyiz. .zip'i kopyaladığımız konuma gidip dosyayı seçersek kurulum tamamlanmış olacak ve aşağıdakine benzer bir çıktı görülecek. Eğer .zip'i sdcarda kopyaladıysak sdcard'ı seçtikten sonra o/, legacy/, obb/ dizinlerinden o/ olan dizini seçmeliyiz. Bu şekilde kurulum tamamlanmış oldu.


İndirdiğimiz .zip dosyasını incelersek içinde SuperSu.apk'sı dışında betikler var, bu betiklerle gereken ayarları yapıp, .apk'yı yüklemeyi gerçekleştiriyor.

Root yetkisi verdiğimizi anlamak için SuperSu uygulaması yüklenmiş mi diye bakmak yeterlidir. Her zaman Supersu .apk'sının sistemde var olması rootlamanın başarılı bir şekilde tamanlanmış olduğu anlamına gelmiyor. Bu yüzden daha iyi bir yöntem ise adb ile telefona bağlıyken su yazınca root hakları veriliyorsa işlem sorunsuz tamamlanmış demektir.

19 Mayıs 2014 Pazartesi

Linux Kernel Geliştiriciliği İçin Bir Fırsat Daha! - Eudyptula-Challenge

Bir süredir Linux Kernel'a nasıl devam edebilirim diye düşünüyordum. Opw'ye katıldığım zamanlar Coccinelle, Sparse ve checkpatch.pl ile yama gönderdim. Bunun dışında smatch var ama smatch ile test yaparak aldığımız hataları çözmek biraz kafa karıştırıcı. Belki bir süre bir şeyler okumuş olmayı gerektiriyor.

Linux Kernel ile ilgili temel kavramlar var. Rcu'lar, birkaç fonksiyon, birkaç makro bunların hepsini okuyup yama göndermeye devam etmeliyim diye düşünmüştüm. Çekirdekle ilgili şeyleri okuduğumuzda hemen anlamak zor aslında oldukça zor gibi. Hatta insanlar bloglarında "artık çekirdek kodlarını anlayabiliyorum!" şeklinde yazılar paylaşıyorlar :) Bu şekilde ne yapsam diye düşünürken geçtiğimiz ay burada eudyptula-challenge sürecini gördüm.

Bu sürece başlamak için "little at eudyptula-challenge.orgadresine e-posta gönderip katılmak istediğimizi belirtmek yeterli. Peki bu süreç nasıl işliyor? E-posta yoluyla uzaktan bir çalışma gerçekleştiriliyor. Tüm e-postalarımızı otomatikleştirilmiş betikler cevaplıyor. Geliştiriciler ile etkileşim içinde bir çalışma değil. Eğer betiğe parse edemeyeceği ya da nasıl çalışıyorsa uygun bir cevap döndüremeyeceği bir soru ya da yapmamızı istediği dışında bir cevap atarsak bu betik e-postamızı geliştiricilere yönlendiriyor. Geliştiriciler ise birkaç gün içinde cevaplıyorlar ancak mümkün olduğunca geliştiricileri bu süreçle uğraşmak zorunda bırakmadan cevaplar göndermeliyiz.

Bu süreç 20 tane görevden oluşuyor. Temel "Hello World" driverından karmaşık driverlar yazmaya kadar ilerliyor. Gönderdiğimiz cevapları html, base64 gibi formatlarda göndermemeliyiz, çünkü betik parse edemiyor. Bir de genelde dosya eki şeklinde göndermemiz gerekiyor. Tarayıcıdan gmail'den göndermek problem oluşturur diye mutt kullanarak cevap atıyorum.

Bense henüz 5. görevdeyim :) Betik biraz yavaş cevap atıyor, şu an bu sürece 4000+ başvuran var. Bir saat içerisinde cevap attığım göreve bir hafta sonra "Bu görevi geçtiniz." e-postası aldım. Bu yüzden süreç biraz yavaş ilerliyor. Bir de bu süreçte yaptıklarımızı github, blog gibi bir yerlerde yazmamalıyız. Çünkü diğer başvuranlar "kopyala-yapıştır" yapmasınlar diye betik bize en başta belirtiyor ve bize bir id veriyor, cevapları bu id ile gönderiyoruz. Çekirdek için çok fazla yazılmış belge var, 3.10 sürümünde Documentation dizini çekirdek deposunun %4'ünü oluşturuyordu. Bu kadar belge arasından kaybolmadan çalışabilmek biraz zor. Belki bunu görebilmek için bir yerlere yazmayın diyorlar.

Aslında bu muhteşem bir fırsat. Tüm görevleri tamamlayamasak bile bir sürü şey öğrenmiş oluruz. İlk dört süreç aşırı temel. 5. süreçte usb driverları ile ilgili işler yapmak gerekiyor. Sonrasını henüz görmedim :).

Çekirdek geliştiricileri de kendini bu işe verebilecek yeni insanlar arıyorlar. Gerçekten çok büyük bir emek gerektiriyor. Ben meslek olarak değil ama sevdiğim ve kendimi geliştirmek için bir fırsat olarak gördüğüm için başvurdum.

Bu süreçte bir süre kısıtlaması ve acele yok. İstediğiniz zaman görevi tamamlayıp cevabı betiğe gönderebilirsiniz. Ortada bir challenge da yok. Sadece görevleri tamamladıkça cevap atmak ve yeni görevi beklemek yeterli.

Eudyptula-challenge'ın resmi sayfasına buradan ulaşabilirsiniz.

9 Mayıs 2014 Cuma

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.

6 Mayıs 2014 Salı

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.

28 Nisan 2014 Pazartesi

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 :)




23 Nisan 2014 Çarşamba

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.

23 Aralık 2013 Pazartesi

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

2 Aralık 2013 Pazartesi

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.

28 Kasım 2013 Perşembe

Ö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 :)

8 Kasım 2013 Cuma

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.

7 Kasım 2013 Perşembe

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