4 Ekim 2017 Çarşamba

C++ Smart Pointers - Akıllı İşaretçiler

C++'da new ile atanan alanların yönetimini manuel olarak yapmamız gerekiyor.
Garbage collector olmadığı için üretilen nesnelerin delete ile silinmesi gerekiyor.
Bu durum gözden kaçırmalarla dangling pointer, memory leak vb. bellek problemlerine sebep olabilir.

Bellek atamaları konusunda daha temkinli olmak için C++ tarafından önerilen yöntem ise smart pointers (akıllı işaretçiler). Bu işaretçiler aslında bir sınıfın nesneleri olarak üretiliyor ve etki alanlarının dışına çıktıklarında sınıflarında bulunan yıkıcılar (destructor) tarafından otomatik olarak siliniyor. Bu sebeple ürettiğimiz objeleri endişe duymadan kullanabiliriz :). Smart pointer'ların bir diğer amacı ise ham (raw, built-in) işaretçilerle aynı söz dizimine sahip olarak kullanılmaktır (-> ve * operatörleri).

Smart pointer'ları std kütüphanesinden alacağımız için #include <memory> 'yi eklemek yeterli.
Bu yazıda auto_ptr artık kullanılmadığı için shared_ptr, weak_ptr ve unique_ptr 'den bahsedeceğim.

== shared_ptr == 
En kapsamlı akıllı işaretçidir. Kullanımı ham işaretçilere en çok benzeyendir. Bir shared_ptr oluşturulduğunda içerisinde referenced-counter adında iki farklı sayaç tutan bir yapı oluşur. Bu sayaçlardan birisi weak_ptr'leri, diğeri ise shared_ptr'leri tutar.

class Foo { ...... };
shared_ptr<Foo> sp1(new Foo);

Buradaki gibi üretildiğinde; shared_ptr, manager obj. ve managed obj. olmak üzere üç tane nesne oluşur.
Bu shared_ptr'ye yeni spr'ler (shared pointer) eklendikçe share sayacı, weak_ptr'ler eklendikçede weak sayacı artar. Aynı şekilde silindikçe de azalır. Ortamda en az bir spr varsa, managed object hayatta kalır. manager objenin ayakta kalması için ise en az bir wpr (weak pointer) ya da spr'nin olması yeterlidir. Eğer ortamda hiç spr yok ama wpr var ise managed obj. silinir, bu objeye spr eklendiğinde yeninden managed obj. oluşur.
shared_ptr'ler, ham işaretçiler gibi dereference edilebilir (*) ve -> ile fonksiyonlarına erişilebilir.

Bir shared_ptr'ye başka shared pointer'lar ve weak pointer'lar eklendikçe durumu aşağıdaki gibi olacaktır:

class Thing {
public:
void defrangulate();
};
shared_ptr<Thing> find_something();
shared_ptr<Thing> do_something_with(shared_ptr <Thing> p);
void foo() {
shared_ptr<Thing> spr1(new Thing);
shared_ptr<Thing> spr2 = spr1;
shared_ptr<Thing> spr3(new Thing);
spr1 = find_something();
do_something_with(spr2);
spr3->defrangulate();
cout << *spr2 << endl;
spr1.reset(); // decrement count, delete if last
spr2 = nullptr; // convert nullptr,  to an empty shared_ptr and decrement count
}
Yukarıdaki örnekteki gibi shared_ptr'yi başka bir spr'ye kopyalarak sayacı bir artırabiliriz. Smart pointer'ları delete ile silmeye çalışmak derleme hatasına neden olacaktır ancak .reset() ile sayacı bir azaltabilir ya da başka bir spr olarak atayabiliriz. .use_count() ise aynı managed obj.'ye kaç tane shared_ptr'nin işaret ettiğini gösterir.

Bir smart pointer'ı, direkt olarak raw pointer'a atayamayız.
shared_ptr<Thing> sp;
Thing *raw_ptr = new Thing;
sp = raw_ptr; // compile error!!!!!!!!
Shared pointer'dan, raw ptr'yi elde etmenin tek yolu .get() kullanmaktır.
Kalıtımda da herhangi bir problem olmadan aşağıdaki gibi kullanabiliriz:

class Base {};
class Derived: public Base {};
….
shared_ptr<Derived> dp1(new Derived);
shared_ptr<Base> bp1 = dp1;
shared_ptr<Base> bp2(dp1);

shared_ptr<Base> bp3(new Derived);

pointer'lar arasında dönüştürme işlemini static_pointer_cast kullanarak yapabiliriz.
shared_ptr <Base> baseptr(new Base);
shared_ptr<Derived> derived_ptr;
derived_ptr = static_pointer_cast<Derived>(base_ptr);
Artık derived_ptr, base_ptr oldu.

İki shared_ptr'yi ==, != operatörleri ile karşılaştırabiliriz. Aynı şekilde if (spr) {..} true dönerse, spr bir objeye işaret ediyor demektir.

Örn. spr3.reset(); dedikten sonra .use_count() sıfır döndürmeye başladıysa, if (spr3) {...} false dönecektir.

Not1: Aynı nesneye işaret eden raw ve smart pointer'ı aynı anda kullanmak tavsiye edilmez, aynı nesneyi iki kez silmeye ya da dangling pointer'a sebep olabilir.

Not2: shared pointer üretirken new ile üretmek iki kere alan tahsisi yapmaya neden olacak ve daha maliyetli olacaktır (İlki new için, ikincisi shared pointer için). Bunun yerine make_shared ifadesini kullanarak bu büyük alan tahsisini tek seferde yapmaya indiregeyebiliriz.

shared_ptr <Thing> spr(new Thing); // two allocations
shared_ptr <Thing> sp(make_shared<Thing>()); // only one allocation

== weak_ptr ==
weak_ptr'ler ancak başka bir weak_ptr ya da shared_ptr sayesinde var olabilirler. Ait oldukları nesnenin yaşam süresine etki etmezler. Dereference (*) etme ve -> operatörü weak_ptr için tanımlı değildir. Bu sebeple weak_ptr'ler zayıf referanslardır (weak reference), genelde ait oldukları shared_ptr'nin hala geçerli olup olmadığını kontrol etmek ya da shared_ptr'ler arasında döngü oluşturan referansları (cycle reference) kaldırmak için kullanılırlar.
.reset() ile içi boşaltılabilir ancak nullptr ataması yapmak mümkün değildir.
weak_ptr'den shared_ptr elde etmek için .lock() kullanılır.
shared_ptr<Thing> sp2 = wp2.lock();
shared_ptr<Thing> sp(new Thing);
weak_ptr<Thing> wp1(sp); // construct wp1 from a shared_ptr
weak_ptr<Thing> wp2; // an empty weak_ptr - points to nothing
wp2 = sp; // wp2 now points to the new Thing
weak_ptr<Thing> wp3(wp2); // construct wp3 from a weak_ptr
weak_ptr<Thing> wp4 = wp2; // wp4 now points to the new Thing

shared_ptr konusunda gördüğümüz shared pointer'ları birbirine atama işlemi döngü referanslarına sebep olmaz. Bu sebeple weak_ptr kullanmak gerekmez.
shared_ptr<Thing> p1(new Thing);
shared_ptr<Thing> p2 = p1;
shared_ptr<Thing> p3 = p2;
shared_ptr<Thing> p4 = p3;

Yukarıda oluşan sadece aynı nesneye referans eden birden çok pointer olmasıdır. Döngü referansları için buradaki örneği inceleyebilirsiniz. Burada örnek çok açık ve temel görünüyor. Muhtemelen çok daha büyük kod bloklarında daha karmaşık bir şekilde döngülerin oluşmasına sebep olunuyordur diye düşünüyorum :). Bu sebeple smart pointer'ları kullanırken dikkatli olmak gerek.

weak_ptr'ler ile dangling pointer'lara engel olma:
shared_ptr<int> sptr;
*sptr = 10;
weak_ptr<int> wptr;
wptr = sptr;
sptr.reset();
.....
..
if (wptr.lock()) { ... }
 // burada direkt olarak sptr üzerinden
 //kullansaydık içeriği boş olan bir pointer kullanmış olacaktık

weak pointer'larda önemli durumlardan bir diğeri ise this objesinin kullanımı. Tamamen ham işaretçilerle kullanımında bir problem çıkmazken, akıllı işaretçilerde problem oluşabilir.
class Thing
{
    public:
        Thing() {cout << "Thing....\n";}
        ~Thing() {cout << "~Thing....\n";}
        void foo();
};

void set_x(shared_ptr<Thing> ptr) {
   ....
}

void Thing::foo()
{
    cout << "Thing::foo() ... \n";
    shared_ptr<Thing> sp(this);
    set_x(sp);
}

int main()
{
  shared_ptr<Thing> t2(new Thing);
  t2->foo();
 ...
}
Burada this raw objesinden yeni bir shared_ptr daha üretiliyor ve bu raw obje aslında daha önceden başka bir shared pointer için kullanılmış. Bu durumda this'in shared_ptr'si silindiğinde, t2 de silinmiş olacak ve t2 silinmeye çalışıldığında zaten silinmiş bir obje tekrar silinmeye çalışılıyor olacak..
Bunu önlemek için kullanılan ifade ise: enable_shared_from_this
class Thing: public enable_shared_from_this()
{
    public:
        Thing() {cout << "Thing....\n";}
        ~Thing() {cout << "~Thing....\n";}
        void foo();
};
...
void Thing::foo()
{
    cout << "Thing::foo() ... \n";
    shared_ptr<Thing> sp = shared_from_this();
    set_x(sp);
}
...

== unique_ptr ==
unique_ptr'de etki alanının dışına çıkıldığında işaret edilen obje silinir. shared_ptr'ye biraz benziyor ancak referenced-counter yok, bu sebeple daha az maliyetli. Sahiplik hakkı ise objeye özel, paylaşımlı bir yapı yok. Copy construction ve copy assignment olmadığı için bir unique_ptr'yi başka bir unique_ptr'ye atayamayız ya da kopyalamayız ancak sahipliği fonksiyondan geri döndürerek bir başka işaretçiye taşıyabiliriz.
unique_ptr<Thing> p1(new Thing);
unique_ptr<Thing> p2(p1); // error, copy construction not allowed
unique_ptr<Thing> p3;
p3 = p1; // error, copy assignment not allowed
..

unique_ptr<Thing> create_unique_ptr()
{
  unique_ptr<Thing> local_ptr(new Thing);
  return local_ptr;
}

unique_ptr<Thing> uptr;
uptr = create_unique_ptr();

Ya da move() fonksiyonu kullanarak da sahiplik hakkı taşıyabiliriz.

Kaynaklar:
http://umich.edu/~eecs381/handouts/C++11_smart_ptrs.pdf
https://cppturkiye.wordpress.com/2016/01/25/c11-zeki-akilli-gostericiler-smart-pointers/

4 Şubat 2016 Perşembe

One of The Largest Events in Europe: FOSDEM


This year, I've been attended Fosdem for the first time. Fosdem is one of the largest events of free software and open source world that happens every january, gathering thousands of the developers (+5000) in Brussels. It is great opportunity to get in touch with the developers of world's leading organisations.

Fosdem has really strong infrastructure to satisfy needs of the attenders.
I've attended the event through Episkey Limited Company's travel fund which is part of Cottange Labs. I've seen the converisation on the mailing list and said if there is any other company that supplies travel fund please let me know because Google have not published scholarship for Fosdem and I could not find another company. Emanuil Tolev has volunteered since 2011 for Fosdem. He replied me and said me and my coworkers would like to sponsor for a person. Then we started a private thread and solved sponsorship requirements. I am thankful for travel grant to Emanuil and Episkey Limited developers.

First day of the event, I've met with Michel, he works as Linux Kernel developer at Intel. We took coffe and talk little. Talking with the kernel developers makes me happy and I really feel very excited. After the meeting, I've discovered the event place, it was at Brussels University, ULB Campus, Solbosh. Fosdem is biggest event that I've attended untill now.

In general, I've joined Main Track sessions. Rspamd is one of my favorites. Vsevolod Stakhov is developer of Rspamd, he told project stages quite clear.

Libreboot and Frosted Embedded Posix OS are my favorites as well. I love to learn about low level software that's why I contribute Linux Kernel. I am former Linux Kernel at Outreachy and would like to keep contribution.

There was an Embedded Systems DevRoom, it was in Building U. I should say, location of the building is hard to find little because there was no sign about Fosdem front of the building. We could not see at least.

In the evening, I've met with my Turkish friends. We have a community photo:


Second day, I've met with Emanuil to talk face to face. He said, I really am glad to sponsor you. That's great to hear.

I've bought tshirts to donate the organisations. It is really great, I am happy to be part of free software and to move it forward.


There was a talk for in memory of Ian Murdock. I would have loved to attend it but I had to leave early because had a flight in the evening. Talks are stored here so far. This is great opportunity to watch the presentation later.

I am very happy about my first Fosdem experience because I improved my network recognizing great folks.

I've seen on the event brochure, it says 8000 developers attended! and you can see diversity at the event. Hope to improve diversity and see underrepresented groups in computer science.

Fosdem is a free event, you can attend without registration. We should donate individualistically or institutionally, if we woud like to see the event in future years.

1 Şubat 2016 Pazartesi

Avrupa'nın En Büyük Etkinliklerinden: FOSDEM


Bu yıl ilk kez Fosdem'e katıldım. Fosdem; Ocak ayında, Brüksel'de düzenlenen, 5000'den fazla katılımcısı olan (etkinlikte dağıtılan kağıtta 8000 yazıyordu), Özgür Yazılım ve Açık Kaynak dünyasının en büyük etkinliklerinden biri.

Fosdem gidip görmeyi çok istediğim etkinliklerden biriydi. Hazır vizem varken Fosdem'e katılmak harika olurdu ve öyle de oldu. Aslında Fosdem'de kısa konuşmaya başvurup, burs alarak katılmak gibi bir planım vardı. Google ve Fosdem'in sayfalarında burs verdiklerine dair bir şey göremedim. O süreçte bu konuşma üzerinden burslardan bahsedildiğini gördüm. Bir süre bekledikten sonra, listeye burs vermek isteyen bildiğiniz başka şirketler var mı? Ben bulamadım. diye yazdım. Fosdem'de gönüllü olarak çalışan Emanuil Tolev yardımcı oldu. Episkey Limited şirketi olarak bu yıl bir kişiye burs vermek istiyoruz dedi. Sonra özelden bir konuşma başlatarak bursu hallettik. Üstelik burs oldukça dolgundu (725€) ve geri ödeme şeklinde değil, etkinlikten önce aldım. Brüksel'de Cuma-P.tesi kalmayı istemiştim ama cuma gecesi ve pazar akşamı şeklinde oldu. Olsundu, etkinlik harikaydı :).

Kısa konuşma başvurum kabul edildi ama ben iptal ettim. Çünkü Outreachy sayesinde tanıdığım birkaç çekirdek geliştiricisiyle görüşme planı vardı ve aynı gün iki heyecanı kaldıramazdım :). Zaten Brüksel'de nefes almaya vaktim kalmadan geçeceği için bu konuşmayı başka zamana erteledim.

İlk gün ben olay mahallini kavrayıp, planladığım kişilerle görüşünceye kadar öğlen oldu. Etkinlik Brüksel Üniversitesi, ULB Kampüs'ünde birkaç binaya yayılmıştı. Binalar arasındaki mesafe çok fazla değil ama peş peşe sunumlara farklı binalarda girmeye yetecek kadar da değil.
İlk gün sunumlara yetişemiyorum yha diye bir miktar homurdandım ancak akşama kadar aynı binada olmaktansa arada başka binalara giderken temiz havayı solumak çok mantıklı :).

Yemek için H binasının ara geçişinden gidilebilen bir kafe var. Sandviçler 3€ ve büyük, ton balıklı olan çok güzeldi. Bir de kampüsün içerisinde karavanlarda satılan sandviç, kızartma, waffle ile yeme ihtiyacını karşılamak da mümkün. Aynı zamanda veganlar için açılan ayrı bir karavan var.

K binası ana bina, Main Track'ler orada yapılıyor ve büyük organizasyonların çoğu orada stand açıyor. Standlardan bardak, atkı, stres topu, polar hırka, havlu, şemsiye, çanta .. ne koymuşlarsa satın alarak organizasyonlara bağışta bulunabilirsiniz. Ben bursum bol olduğundan dilediğimce aldım diye düşünürken, Arda tüm standları topladı :). Arda, Open Media odasında sunum yaptı. Ben yine mükemmel zamanlamamla kaçırdım. Aslında kaçırmadım, ben gittiğimde kapının üzerinde kocaman FULL yazıyordu. Bir de Tuna arguman.org hakkında konuşma yaptı.

Fosdem'e yakın zamanlarda yapılan Fosdem Fringe adında bir oluşum var, farklı organizasyonlar kendilerine özel etkinlik düzenliyorlar. Gülçin Yıldırım Fosdem PGDay'de sunum yaptı, biz öncesinden Fosdem'de görüşmeyi planlamıştık. İlk günün akşamı etkinliğe katılan birçok Türkle görüşme fırsatım oldu. Bu da fotoğrafımız:

Sadece bu kadar değildik, ikinci gün üniversiteden arkadaşlarımla buluştum. Şu an Kartaca'da çalışan ekip, toplanıp Fosdem'e gelmişler. Onlarla görüşme fırsatı bulmak harikaydı. İkinci gün aynı zamanda Emanuil ile görüştüm. Bana burs vermiş olmaktan çok mutlu olduklarını söyledi.

Bunlar da etkinlikten aldığım tişörtler. Suse'li olanın üzerine sanırım PostgreSQL çantasının rengi geçti :(. Etkinlik günleri oldukça yağışlıydı, benim bile rengim geçmiş olabilir :p.


Bu da gördüğünüz gibi Perl'ün devesi :).


Katıldığım sunumlar ise pek az ama çevremi genişlettiğim bir etkinlik olduğu için hiç sorun değil. Benim hazırladığım program kayınca, katılmak istediğim sunumlarda da kocaman FULL yazınca Main Track'tekileri dinlemeye karar verdim. Ian Murdock'un anısına bir konuşma vardı, uçağa yetişmek için pazar öğleden sonra olmadığımdan katılamadım. Konuşmaların kayıtları aynı zamanda burada tutuluyor. Eski arşivlere bakmak isterseniz de burası.

Girdiğim sunumlardan en beğendiklerim, Libreboot ve Embedded POSIX OS oldu. Gnu Guile'ı çok merak ediyordum, baştaki sunumlara girmeyince sonradan katılmak biraz balıklama oldu. Gnu Guile bir programlama dili ve Fosdem'de organizasyonlar kendilerine Dev Room'lar ayırabiliyorlar. Gnu Guile'ın da bir odası vardı :).

Rspamd'yi tanıtan arkadaş projenin adımlarını çok güzel açıklamıştı. Fark ettim de, en çok alt seviye yazılımlarla ilgili şeyler dinlediğimde mutlu oluyorum.

Bir de aklınızda bulunsun, Brüksel'de taksiler çok pahalı. Gece on birde binip, 20 dk ancak yol gittik ve 50€ verdim. Gündüz de çok fark etmedi, 42€ verdim. Sonra sordum, lüks taksiye mi bindim acaba neden bu kadar pahalı? Tüm taksiler aşağı yukarı aynıymış. Dublin'de hava alanına gitmek için Air Coach'lar var ve 7-10€ arası. Taksiyle giderseniz hava alanı o kadar uzak olmasına rağmen merkezden tutan miktar 20€. Söyleyeceklerim bu kadar :p.

Fosdem, ücretsiz katılınabilen bir etkinlik. Eğer anahtar imzalamaya katılmayacaksanız etkinlik öncesi kayıt tarzı bir şey yapmanız gerekmiyor.

K ve H binasında Fosdem tişörtlerinden alarak ya da almadan Fosdem'e 25€dan başlayarak bağışta bulunabilirsiniz. Bu güzel etkinliğin bu şekilde devam etmesini istiyorsak, şirketler ya da bireyler olarak destekleyelim.

28 Kasım 2015 Cumartesi

CV Hazırlama Üzerine Tavsiyeler

Geçtiğimiz günlerde WomENcourage Konferansı'na katılmıştım. Etkinlikteki kariyer fuarında İntel'in standına uğradım. Standdaki çalışanlarla tanışıp, hangi alanlarda çalıştığım hakkında konuşma fırsatı buldum. Standa şu anki açık pozisyonlarından bir kısmının çıktısını alıp, gruplara ayırarak koyduklarını gördüm.

Standda Bev ile iletişime geçtim. Etkinlik akşamı güncel cv'mi ona gönderdim. Bunun üzerine bir Skype görüşmesi ayarladık. Bana sıkı çalışmışsın ama proje detaylarını (amacı, önemi, yararı vs.) yazmamışsın dedi. Bu yüzden cv'min insan kaynaklarında çalışan birine açık olmadığı belirtti.

Bunun üzerine Google Doc belgesi açarak orada cv'mi baştan yazmaya başladık. Açıkçası kendimi tanıtırken etkili cümleler yazmak konusunda pek yetenekli değilim ve bu zamana kadar bunun çok da önemli olmadığını düşünüyordum (hala bir miktar öyle düşünüyorum :p). Bev de bunu fark ettiği için bana çok yardımcı oldu.

Bev'e ilk gönderdiğim cv'yi buradan inceleyebilirsiniz. Birlikte hazırladığımız cv ise burada. Özellikle yurtdışında bir yere başvuruyorsak şu anki konumumuzu belirtmeliyiz. Eski cv'me ek olarak: Profile, Key Skills and Experiences, Project History alanlarını ekledik ve Professional Experiences kısmına açıklamalar yazdık.

Profile kısmında; kendimi kısaca tanıtıp, ilgi alanlarımı belirttim. Key Skills and Experinences kısmında çalıştığım alanları alt başlıklara ayırıp, hangi görevleri üstlendiğimi yazdım. Project History kısmında ise sahip olduğum deneyimleri nasıl kazandığımı yazdım. Şimdi şurada çalışıyorum, daha önce şuralarda çalıştım şeklinde. Bev'in Red Hat'te çalışan bir arkadaşı var. Söylediğine göre o arkadaşı cv hazırlama konusunda çok iyiymiş. Bana yardım etmek için arkadaşıyla iletişime geçeceğini söyledi. Bir süredir arkadaşından gelecek cevabı bekledim (hala bekliyorum) :). Bir aya yakın bir zaman geçince bu yazıyı artık yayınlamam gerektiğini düşündüm. Zaten Bev de cv'min bu halinin eskisine göre çok daha iyi olduğunu söyledi.

Cv'de sen bu cümleleri nasıl hazırladın diye soracak olursak, Bev bir şey yazamadığımı görünce İntel'in iş ilanlarına (ya da başka bir firma) bakarak, kendinde oradaki gibi ilgi çeken cümleler kurabilirsin dedi, zaten yazmama Bev de yardım etti. Yani başvuracağımız şirketin tanımlarına bakıp oraya çok uygunmuşuz gibi cümleler kuruyoruz :p

Cv'de olması gereken diğer şeyler; telefon numarası, kullanmıyorsak bile bir github hesabı linki (mülakata almak için github hesabı olmasına bakan firmalar var), yaptığımız sunumlar varsa onları da eklemeliyiz.

Günlük tutuyor olmak iyi bir cv için gerçekten önemli. Günlükte teknik konularda yazmak, kişinin nasıl öğrendiği, nasıl çalıştığı, hangi yolu izlediği, sonuca nasıl vardığı hakkında karşı tarafa bilgi veriyor.

Bev bana WomENcourage gibi katıldığın başka önemli etkinlik var mı diye sordu, varsa onları da eklememi söyledi.

Eğer hakkında bir miktar bilgimiz olan ama çok uzun süre çalışmadığımız konular varsa "I am familiar with .." şeklinde yazmak gerçekten çok mantıklı :). Geçtiğimiz yıl bir yerde denk gelip görmüştüm.

Yukarıda linkini verdiğim eski cv'yi Rik'le birlikte, Red Hat başvurusu zamanında hazırlamıştım. Bu zamana kadar ne zaman cv hazırlamam gerekse hep gel cv'ni birlikte hazırlayalım diyen birileri oldu. Bu konuda çok şanslı olduğumu düşünüyorum. Bev'le birlikte ilk kez bir İK çalışanıyla cv hazırlamış oldum.

Bev'in arkadaşından da tavsiyeler alırsak bu yazıyı güncelleyeceğim. diff'ini alıp paylaşırım :)

19 Ekim 2015 Pazartesi

WomENcourage Konferansı - 2015

Geçtiğimiz günlerde İsveç'in Uppsala kentinde düzenlenen WomENcourage etkinliğine katıldım. Neden WomENcourage, anlatsana biraz diye sorarsak açalım. Bir süredir Google'ın seyahat bursu verdiği etkinlikleri bu sayfadan takip ediyorum. Beğendiğim etkinlikleri not edip, uygun zamanlarda bursa başvurarak katılmak gibi bir planım var (aslında beğenmediğim etkinlik yok ama naparsın :b). WomENcourage isminden de anlaşılacağı gibi gitmeyi çok istediğim bir etkinlikti. Ancak bu sene LinuxCon'a katılacağım için WomENcourage'a başvurmaktan vazgeçmiştim. LinuxCon 5-7 Ekim'de İrlanda'da, WomENcourage 24-26 Eylül'de İsveç'te oldu. İkisine farklı vizeler gerekiyor ve vize almaya zaman yetmez diye düşündüm.

Bu düşüncelerden birkaç hafta sonra  Google'ın Dablin'deki ofisinden bir eposta aldım. Epostanın içeriği şu şekilde: Daha önce iş arkadaşlarımla görüştüğün için senden haberdar oldum, biz bu sene WomENcourage konferansı için burs vermeye başladık. Başvurmak ister misin? Buradan anladığım kadarıyla geçen sene Dablin ofisine iş görüşmesine gitmemden dolayı tanıdığı söylüyor. İlgili yazı için bknz.: Google Mülakatları

Şansımı denemek için teklifi kabul edip, başvurdum. Başvuru formunda cv dosyası, linkedin hesabı istiyorlar. Herhangi bir soru çözme, kod yazma gibi bir şey yok. Birde hayatta en çok gurur duyduğunuz, heyecanlandığınız proje nedir ve neden en çok onunla gurur duyuyorsunuz gibi bir soru vardı. Ben Outreachy aracılığıyla yaptığım Linux çekirdeği stajımı yazdım.

Başvuru sonuçları açıklandığında bursa kabul edildiğimi öğrendim \0/. Peş peşe iki vize başvurusu gerektiğinden süre yeter mi diye kaygılandım ama her şey beklediğimden daha iyi gitti :). Google seyahat bursunun içeriği şu şekilde, etkinlik için bilet + 1000€'ya kadar masraf bedeli. Herhangi bir fiş sunma zorunluluğu olmadan bu bedeli veriyorlar (ama yinede fişleri ödemeyi alana kadar saklamamı istediler). İsveç için verdikleri burs: konferans bileti + 800€ oldu.



Etkinliğin ilk günü hackathon ve kariyer fuarına katıldım. Ben vardığımda Hackathon'da gruplar ve projeler belli olmuştu. Ben de sayıca az olan bir gruba eklendim :). Projemizin konusu gaz sızmasını en erken şekilde tespit edip, insan hayatını korumaktı. Bunun üzerine proje tasarımı, sunumu ve basit bir simülasyonunu yaptık. Simulasyonu Edison Board kullanarak gerçekleştirdik. Hackathon'da çok yaratıcı olan başka projeler vardı. Düştüğümüzde kimseden yardım alamayacağımız durumlar için uygulama ve şehirde bisiklet sürümünü daha güvenli hale getirmeyi amaçlayan uygulama aklımda kalanlardan.















Kariyer fuarında Googlçalışanlarıyla tanışarak burs kazananlara hediye edilen çantayı aldım. Charlie beni Mine'yle tanıştırdı. Mine, Google'ın Londra ofisinde çalışıyor. Orada bizden birilerini görmek gerçekten çok sevindirciydi. Sadece bu kadar değil, Bilkent Üniversitesi'nden Reyyan hoca etkinliğin organizatörlerinden! Birde Uppsala'da yüksek lisans yapan Tuğçe ile tanıştım. Tuğçe, bilgisayar bilimlerinde yüksek lisans yapıyor. Etkinlik akşamı, orada yüksek lisansın nasıl gittiği hakkında konuşma fırsatımız oldu.


Fuarda Intel'de çalışan bir kadınla tanıştım. Bana eposta adresini verip kendisiyle iletişime geçmemi istedi. Bugünlerde onunla görüşüp cv hazırlıyorum, bana bu konuda danışmanlık ediyor. CV hazırlamayla ilgili kısa bir yazı yazmayı düşünüyorum.

Google'da çekirdek seviyesinde çalışmak istersem genelde android tarafında iş bulabileceğimi öğrendim. Birde eğer yurtdışında yüksek lisans / doktora yaparsam, muhtemelen burslu yapacağım, bu konuları konuşabileceğim birkaç kişinin eposta adresini aldım.

Etkinliğin asıl amacı insanların tanışıp, çevre edinmesi olduğundan çok yoğun sunumlar yoktu. En çok beğendiğim sunumlardan biri Facebook'ta çalışan kadının yaptığı sunumdu. Benim de hala aklıma şanslı olduğum için işe alındım, benden başka başvuran kimse yoktu o yüzden aldılar gibi düşünceler geliyor ama aslında öyle değil. Kendime bir şeyleri yaptım, başardım ve alındım diyorum dedi.

Bir diğer sunum ise Anita Borg bursuyla doktora yapan arkadaş oldu. O da alınmayacağını düşündüğü için ilk senesinde bursa başvuru yapmadığını, daha sonra başvurup alındığını söyledi. Bu seneki burs miktarı 7000€ imiş. Üstelik burs sadece doktora için değil, lisans ve yüksek lisansta da başvurulabilen bir bursmuş (sadece doktora için sanıyordum ^_^).

İsveç'te güzel anılar gibi güzel diyebileceğim günler geçirdim. Gezmeye vakit bırakmak için birkaç gün fazla kaldım. Boş olan günümde trenle Stokholm'e geçtim. Tam bir harikaydı. Şehre aşık oldum. Gamla Stan'ı beni buraya gömün diyerek gezdim. City Hall de kesinlikle görülmesi gereken yerlerden. Viking Kuleleri'ne asansörsüz çıkarken yaşanacak durum gerçekten harika. İnsanı sayamadığım kadar yıl öncesine götürüyor :).

Uppsala ve Stockholm'de çektiğim fotoğraflara buralardan bakabilirsiniz.

Stokholm'den sonra LinuxCon için Dablin'e gittim ve sunum yaptım ^_^. Onu da bir yazımda paylaşacağım.




8 Eylül 2015 Salı

Git'te Yama Uygularken Oluşan Çakışmaları Çözmek


Yazma iznimizin olmadığı depodaki projeye katkı verme işlemini yama dosyası oluşturarak yaparız. Yama dosyaları karşı tarafa yaptığımız değişiklikleri insan okuyabilir şekilde özetler. Bu konu hakkında kısa bir yazı yazmışım, buradan bakabilirsiniz.

Github üzerinden geliştirdiğim kendi projelerime olan katkıları kabul ederken terminal kullanmadan, web sayfası üzerinden hallediyorum.

Linux çekirdeğinde her takım farklı alt dizinlere baktığından ve çoğu github kullanmadığından işlemleri konsol üzerinden yapmak gerekiyor.

Linux çekirdeğinde uzunca bir süredir büyük bir yama  setini kabul ettirmeye çalışıyorum. İnsanlık için küçük olabilir ama benim için büyük demeden geçmeyelim. Yamanın konusu özetle bellek üzerinde büyük bir baskı olduktan sonra swapten dönerken, ihtiyaç duyulmayan sayfaları da swapten belleğe getirip büyük sayfa oluşturarak, performans sağlamak.

Bu yama uzun bir sürece girdiğinden, linux çekirdeği sürekli güncelleniyor ve benim değişikliklerim deponun eski halindeki gibi kalıyor. Bu durumda karşı taraf uygulamaya çalışırken çakışma oluşacak, yama bu nedenle reddedilecek.

Eskiden hep küçük değişiklikler yaptığımdan ve daha kısa süreçte bittiğinden, kendi yamamı güncel depoya uygulama ihtiyacı duymadım. Her satırı tekrar kontrol ederek yeniden oluşturuyordum. Yama büyük olduğunda işler böyle olmadı. Her satırı tekrar oluşturmak çok zor ve derlemede hata almıyorsam bile mantıksal hata yapma ihtimalim çok yüksek.

Değişiklikleri uygulamadan önce git apply --check yama_dosyası şeklinde yamanın uygulanabilir olup olmadığını kontrol edebiliriz. Eğer git apply yama_dosyası komutunu verirsek, yamayı commit yapmadan depoya ekler. Bu durumda değişiklikler commitlenmediği için de git diff ile farkları görebiliriz. Bu bize yama dosyasını ekleyip, commit yapmayarak elle başka değişiklikler yapmaya olanak verir. Tüm değiştirmek istediğimiz dosyalar bittikten sonra kendimiz git commit -a komutuyla değişiklikleri loglayabiliriz.

Yamanın commit yapılarak depoya eklenmesini istiyorsak git am < yama_dosyası şeklinde uygulamalıyız.

Eğer daha önceden yaptığımız commitlerde düzenlemeler istiyorsak git rebase harika bir araç. Onunla ilgili daha önceden bir yazı yazmıştım, buradan bakabilirsiniz.

Yama uygularken geçenlerde karşılaştığım durum, yamanın (muhtemelen) güncel depoyla uyumlu olmamasından kaynaklıyordu. Hata aldığım makine çok sık kullandığım bir makine değildi, belki daha önceki başka bir şeyden kaynaklanıyor da olabilir. Hata mesajı şu şekilde:

Applying: mm: add tracepoint for scanning pages
error: include/trace/events/huge_memory.h: already exists in working directory
error: patch failed: mm/huge_memory.c:2673
error: mm/huge_memory.c: patch does not apply
Patch failed at 0001 mm: add tracepoint for scanning pages
The copy of the patch that failed is found in:
   /home/ebru/linux-stable/.git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

Bunu görünce daha önceden aynı commitler depoda vardı, bu yüzden bir yerde indeksleri tutuluyor düşündüm. mv linux-stable/.git/rebase-apply ..path/ ile rebase-apply dizinini başka bir yere taşıdım. Tekrar yamayı uygulamaya çalıştım yine aynı hatayı aldım (kaldırdığım dizin tekrar oluştu).

Bunun çözümü şu şekilde hatayı aldıktan sonra, git apply linux-stable/.git/rebase-apply/patch --reject komutunu veriyoruz. Bu sayede yamanın çakışma oluşturmayan kısımları depoda oluşturuluyor.

Checking patch include/linux/mm.h...
Checking patch include/trace/events/huge_memory.h...
error: include/trace/events/huge_memory.h: already exists in working directory
Checking patch mm/huge_memory.c...
Hunk #1 succeeded at 30 (offset 1 line).
Hunk #2 succeeded at 2270 (offset 53 lines).
Hunk #3 succeeded at 2307 (offset 53 lines).
Hunk #4 succeeded at 2319 (offset 53 lines).
Hunk #5 succeeded at 2327 (offset 53 lines).
....
       ........
Hunk #13 applied cleanly.
Hunk #14 applied cleanly.
Hunk #15 applied cleanly.
Hunk #16 applied cleanly.
Rejected hunk #17.
Hunk #18 applied cleanly

Bu şekilde uygulanan/uygulanamayan kısımları özetliyor. Uygulamada sorun oluşturan her dosya için uygulanamayan kısımları dosya_adı.rej uzantılı diff dosyası oluşturarak bize gösteriyor. Bu dosyaları git status ile bakarsak görebiliriz. Bu süreçte depo aslında rebase etme gibi git apply sürecinde oluyor. Yamanın uygulanmayan kısımlarına .rej uzantılı dosyalardan bakıp, kendimiz dosyaları açıp değişiklikleri yapıyoruz. git status ile tekrar bakıp eklememiz gereken dosyaları git add ile ekledikten git am --resolved ile işlemi sonlandırıyoruz. Bu şekilde çakışma oluşan yama dosyalarını depoya uygulamış olduk.

Çakışma çözme işlemini bu yazıdan okuyarak öğrendim. Umarım benim yazım da faydalı olmuştur.

5 Ağustos 2015 Çarşamba

Red Hat'te Linux Çekirdeği Geliştiriciliği

Geçtiğimiz kış Outreachy'de Linux çekirdeği üzerinde, Red Hat'te çalışan Rik van Riel'in danışmanlığında staj yaptım.

Staj bitiminde Rik istersen Red Hat'te birkaç pozisyona başvur, ileride seninle birlikte çalışmak isterim dedi. Aslında birkaç sene daha Türkiye'de kalma kararımı Google görüşmesinden sonra vermiştim ama Red Hat'te çalışma düşüncesi de geri çevirilemez bir şeydi, o yüzden kabul ettim.

İlk önce jobs.redhat.com adresinde ilgimi çekebilecek olan işlere baktım. Rik deneyimli çalışan aradıklarını söyleseler bile, yeni başlayan pozisyonunda da iş bulabiliriz dedi. Open Stack, Sanallaştırma ve Arm işlemciler için çekirdek geliştirimi olarak 3 farklı pozisyona başvurdum. Bu üç pozisyon üzerinde de hiç deneyimim yok ancak daha uygun pozisyonlar bulamadım. Zaten onlar da deneyimi olmayan eleman alacaklarını biliyorlardı.

Open Stack ekibi İstanbul'dan taşınman gerekir, bu gibi durumlarda deneyimsiz geliştriciler yerine kıdemli olanları tercih ediyoruz ama sen şansını deneyip mülakatlara gir dedi. Sonrasında kıdemli elemana daha çok ihtiyaçları olduğunu belirttiler, diğer görüşmeleri yapmadık.

Sanallaştırma ekibi aynı zamanda Rik'in çalıştığı ekip. KVM ve Qemu'yu geliştiriyorlar. Sanallaştırma pozisyonu için öncelikle başlangıç görüşmesi yaptık. 2 hafta sonrasına gün belirleyip ilk mülakata girdim. En fazla teknik soruyu ilk mülakatta aldım, sorular zor değildi. Glassador'dan okuduğum kadarıyla Red Hat için soruları zor olmuyor yazıyordu. İlk görüşmede spinlock, zamanlama gibi temel çekirdek kavramlarından sordu. Yeni bir konu olsa da gerçek zamanlı algoritmalar üzerinde yorum yapmamı istedi. Üniversitede en sevdiğim dersler, staj projemde neler yaptığım, bir yamayı kabul ettirene kadar en fazla kaç sürüm gönderdiğim, stajda kabul edilen yamaların çekirdeğin kaçıncı sürümünde olduğu, Rik'le nasıl çalıştığım, kodlamaya nasıl başladığım .. şeklinde devam eden staj sürecimin her evresinden sorular aldım. Görüşme sonunda bir sonraki adıma geçtiğimi öğrendim \0/.

Sonraki adım 5 farklı mühendisle görüşmeyi içeren bir paket gibi. Bu görüşmelerin hepsi aynı günde olmak zorunda değil ve her biri yaklaşık 50 dk sürüyor.

Red Hat görüşmeleri Google'ınki kadar zor değil ve görüşme zamanlarını istediğimiz kadar geniş bir süreye yayamıyoruz. İki görüşme arasındaki süreyi Google pek önemsemezken, Red Hat'teki arkadaş senin yerine başka birini işe alabilirler, bu yüzden görüşmelere ne kadar erken girsen o kadar iyi demişti.

Diğer görüşmeler çok az teknik soru içeriyordu. Genelde stajda neler yaptığım üzerine konuştuk. Bir gün iki görüşmeye birden girdim. O akşam pek yorucuydu diyebilirim. Birde Google görüşmelerinde bu kadar heyecanlanmadım. Sanırım 3. görüşmeden sonra normal heyecanda konuşabildim.

Son görüşmeyi Rik'in içinde bulunduğu takımın yöneticisi olan bir kadınla yaptık. Tüm görüşmeler içindeki tek kadındı. Görüşebileceğim en yüksek mercideki kişiydi.

Son görüşme çok eğlenceli geçti. Bir iş görüşmesinden ziyade bir arkadaşımla konuşuyormuşum gibiydi. Teknik sorular yok denecek kadar azdı. Çanakkale'den, şimdiki işimden, neden çekirdek üzerinde çalıştığımdan, Türkiye'den taşınma durumumdan konuştuk.

Bu görüşmeden bir iki hafta sonra Red Hat'te işe alındığımı öğrendim, Brno'da çekirdek geliştiricisi olarak çalışacaktım.

Birkaç aydır pek iyi değildim, rahatsızlığım zirveye ulaştığında doktora gittim. Şimdilik çok ciddi bir rahatsızlığım yok ancak İstanbul'dan taşınmaya yetecek kadar da iyi değilim, ülkeyi değiştirmek zaten zor bir durum .. Ben bu kararsızlıklar içerisindeyken Red Hat'e de bunu söyledim, taşınmam 4 ay sürer, ben birkaç ay daha geciktirsem gitmeyi derken Red Hat'ten gelen maaş teklifi çok az oldu. Birde taşınma masraflarını zaten karşılamıyorlar. Bir iki firmadan duyduğum kadarıyla taşınma konusunda çok yardımcı olan yerler de var ..

Brno netten gördüğüm kadarıyla pahalı bir yer değil, ancak Red Hat'in €1k'nın biraz altında maaş teklif etmesine şaşırdım. Mezuniyetten sonra bir seneye yakın bir zaman evden çalıştım ve bu zamanı çok da fazla karşılık almayarak geçirdim. Başarılı projelere bu şekilde katkı vermek bir süreliğine benim için kabul edilebilir bir şey. Ancak bunu yurtdışındayken ve sağlığım da şuan için çok iyi değilken kabul etmedim.

Aslında Red Hat kabul etmediğimde evden çalışmayı teklif etti, kabul ettim ancak sonrasında yeni başlayanların bir sene boyunca ofiste çalışması gerektiğini ve ilk yıldan sonra evden çalışma izinlerinin olduğunu söyledi. Neticede maaş ve rahatsızlığım nedeniyle kabul etmemiş oldum. İk'daki arkadaşa Brno'da çalışmayı İstanbul'da birkaç sene çalıştıktan sonra olsaydı kabul ederdim, dedim. Daha sonraki bir zamanda eğer çalışmak istersem kendisiyle iletişime geçmemi istedi.

Bugünlerde kendime iyi bakıp, daha sağlıklı yaşayarak hayatımı düzene oturtmaya çalışıyorum. Zaten öğrenciyken de yaşama şeklimi değiştireceğim diyerek kendime bu sözü vermiştim. Ben bu sözü tutmaya başlamadan önce, vücudum bana uyarıyı verdi :p. Aslında çok önemli şeyler değil ama çok geç saatlere kadar uyanık kalmamak, az tuzlu yemek, sağlıklı beslenmeye çalışmak gibi okul temposundan sonra daha normal koşullarda çalışmayı düşünüyorum :).

Yurtdışına yine giderim, sonraki zamanlarda karşıma daha iyi koşullarda başka fırsatlar çıkar diye ümit ediyorum.

25 Mayıs 2015 Pazartesi

Google Mülakatlarına Hazırlanma Süreci

Geçen yaz Google ik'dan (insan kaynakları) profilinizi linkedin, github ve birkaç listeden inceledik kabul ederseniz başlangıç bir görüşme yapmak isteriz içerikli bir e-posta aldım. 2 gün sonra başlangıç telefon görüşmesini ik ekibinden bir arkadaşla yaptık. Görüşmenin 45-55 dk arası sürmesi bekleniyor, benim bir saati biraz geçmişti. İlk görüşmede kod yazmamı gerektirecek bir şey sormadılar. Veri yapıları, ağ bilgisi, bit düzeyinde işlemler, algoritmalar ve karmaşıklıkları, bash komutları, sistem çağrıları, süreçler hakkında sorular geldi. İlk görüşmede tanışma, ilgi alanlarını öğrenme, hangi işler üzerinde uğraştığın hakkında bilgi edinme gibi kısımlardan da konuşulduğu için teknik değil olarak adlandırıyor ancak bence gayet teknikti :). Görüşme sonunda, ilk adımı geçtiğimi öğrendim.

Daha önce bir iş tecrübem olmadığı için bir alan seçmem gerekiyordu, telefondaki arkadaş Site Reliability System Engineering (SRE) ve Software Engineering olmak üzere 2 pozisyon sundu. Bilgilerin sistem tarafı için daha uygun istersen SRE seç şeklinde öneride bulundu. SRE görüşmelerinde daha başarılı olacağımı düşündüğümden onu seçtim.

Başlangıç görüşmesinden önce çok gerildim, zaten nasıl konuşacağım kısmı ayrı bir olay :). Soruları bitirdikten sonra, görüşmeyi yapan arkadaş diğer adımlar için tavsiyelerde bulundu, sorular üzerinde sesli düşün, eğer ne sorulduğunu anlayamadıysan bilmiyorum deme, anlayana kadar sorman sorun değil, dedi. Çünkü söylediği bir kelimeyi anlayamadığımdan bilmiyorum demiştim, anlamadığımı fark etti ve gtalk'a sorunun bir kısmını yazdı ve cevapladım :).

İkinci görüşmeyi bir mühendisle yine telefon üzerinden yaptık. Kodlama soruları için google doc kullandık. Görüşme yine 45-55 dk arasıydı. Soruların neredeyse hepsi çalıştığım sorulardı ancak düzenli ifadelere çok fazla çalışmaya vaktimi yetiremedim. Görüşmede son soru basit split, join işlemleriyle çözülebilecekken suçluluk psikoljisi ile düzenli ifadelerden çözülmesi gerekiyor sandım :). Çözüme yaklaştım ancak çoğu şeyi göz ardı ettik, ben ifadeleri karıştırdım gibi şeyler oldu. Görüşme sonunda mülakatı yapan arkadaş, bu görüşmenin büyük kısmını harika yaptın dedi. Bir an şok olmamla birlikte havaya uçup geri oturdum :).

Google'ın mülakatlarına hazırlanırken aşağıdaki linklerden yararlandım. Bunlar dışında deneyimler üzerine yazılmış çok fazla blog yazısı bulabilirsiniz. Hepsini okumak belki mümkün olmaz ama çoğunu okuyun gerçekten çok faydalı oluyor. Mühendislerle yaptığım görüşmeler ik'daki arkadaşla yaptığım görüşme kadar eğlenceli geçmedi. İk'da olan arkadaş görüşme sırasında harikasın, çok iyi gibi sürekli destek olarak ve çok sevecen bir şekilde konuşuyordu. Ancak mühendisler süreci soğuk, sadece soru soran ve cevap bekleyen bir şekilde geçiriyorlar. Okuduğum bir blog yazısında telefonda problem olduğu için Skype'a geçmek zorunda kalan bir arkadaş mühendis soğuk ve sıkılmış görünüyordu yazmıştı. Bu yüzden telefondaki soğuk tavırları hiç üzerime alınmadım :), sadece en sonda tebrik eden bir ifade duydum.

Siteler: Geeks For GeeksGlassadorCareerupCracking Code InterviewsSystem DesignDevops Interview Questions.

3. mülakat için yeniden tarih belirledik. Genelde 3 er hafta arayla yaptık görüşmeleri. İlk iki görüşmem iyi geçtiğinden sonuçlarını hemen öğrenmiştim, normalde bir haftayı bulabiliyor. Görüşmelerin arasını çok uzatmak bence iyi değil, sonuna kadar gidebileceğimizi düşünürsek insan bunalabilir. 3 hafta gayet iyi bir süreç. Zaten görüşme 45 dk sürüyor, en fazla kaç soru sorabilir diye görüşmeden önce kendimizi rahatlatmak da bir yöntem :). Birde hazırlanırken süremi bir hafta kadar tanım sorularına çalışarak, bir hafta kodlama sorularına çalışarak sonraki hafta bunları karmaşık tekrar ederek geçirdim.

3. görüşme görüntülü olacaktı ancak ne olduysa yine telefon üzerinden yaptık. Bu görüşmede sorular beklediğim gibi değildi. Temelde bir soru sorup, diğer soruları aynı soru üzerinden türetti. Görüşmenin nasıl geçtiğini anlamadım, soyut şeyler üzerinden benim daha önce deneyememiş olacağım şeyler üzerinden konuştuk. O zamanlar her görüşmenin bitiminde sonucu söylüyorlar sandığımdan bu adımı geçebildim mi? diye sordum, henüz bilmiyorum cevabını aldım :). Bir hafta sonra geçtiğimi öğrendim.

Buradan sonraki adım Google ofisinde yapılması gereken görüşme. Yine ik'daki arkadaş önce aradı sonra aynı bilgileri e-posta ile gönderdi. Birkaç Google pozisyonu önerdi, Dublin'de olanı seçtim, Dublin aynı zamanda Google'ın Avrupa'daki ofislerinin merkezi. Vize işlemleri nedeniyle ve benim gideceğim haftada Dublin'de etkinlikler olduğundan, son görüşmeyi 1,5 ay kadar ertelemek zorunda kaldık :(.

Son mülakat 45'er dakika şeklinde ve 5 oturumdan oluşuyor. Her oturuma 1 ya da 2 mühendis girebiliyor. Son oturumu SRE takımının yöneticisiyle yaptık ^_^.

Son aşama gerçekten çok heyecanlıydı. Uzaktan yapılan görüşmeler sırasında sesin kesilmesi problemi çok oluyor. En sonunda duyamıyorum, sesin kesiliyor dediğimde google doc'a soruyu yazdıkları olmuştu. Yüzyüze görüşmede çok hızlı konuşurlarsa diye sıkıntım vardı ancak öyle olmadı. Google çalışanları konuşma konusunda diğer şirketlere göre çok daha anlayışlı. Oldukça anlaşılır konuşuyorlar.

Konuşma pratiği yapmak için dil kurslarına gitmek faydalı, birde Google SRE ekibinin düzenlediği etkinlikleri youtube'dan çok rahat bulabilirsiniz. Ben onları izlemiştim, hem birkaç anahtar kelime öğrenmemi sağladı hem anlamamı geliştirdi.

Mülakatın yapılmasından bir gece önce Dublin'deydim. Sabah ik'daki arkadaş istersen otelden seni alayım, yürüyerek gayet yakın dedi. Kabul ettim, çok yağmurlu bir sabahta ofise birlikte gittik. Her oturumdan sonra 3-5 dk beklemek gerekebilir, bu sürelerde eğer odada yalnız kalırsam dışarı çıkmamamı ve henüz çalışan olmadığım için ofiste tek gezmememi söyledi.

Son görüşmede soruların çoğunluğu çalıştığım yerlerden çıkmadı. Bu kadar sorulmaz ya dediğim ve ayrıntısına inmediğim şeylerden çıktı. Açıkçası hiç beklememiştim. Daha önce bir yerde de öyle soruları görmedim :(. Basit sorulan sorular da vardı elbette ama geneli değildi. Çok iyi veri yapıları soruları bekliyordum, hiç sormadılar :|.

Ancak sürecin tamamı çok heyecanlı ve cesaretlendiriciydi. Yüzyüze yaptığımız görüşmelerdeki arkadaşlar da çok sevecendi, bir soğukluk yoktu :). Birde yurtdışına ilk seyahatimi Google sayesinde yapıyor olmam da çok mutluluk vericiydi.

Google'ın sizle görüşmek isteriz şeklinde e-posta atması için sadece bir github hesabımız olması bile yeterli. Çünkü onlar da yeni insanlar tanıyıp, onları görüşmelerine hazırlamak istiyorlar.

Üniversiteden "olmadı sanırım .. olduğu kadar :(" şeklinde hissederek mezun olmuştum, bunun üzerine Google görüşmesinin bu kadar ilerlemesi çok iyi oldu, çok da güzel oldu :). Mezuniyetimden sonra 7-8 ay boyunca kadar her şey böyle karmaşık ve heyecanlı bir şekilde ilerlerdi. Bir hafta önce bundan sonrası şöyle olur muhtemelen dediğim şeylerin hiçbiri tutmadı :), şimdi tekrardan her şey düzene girdi. Bundan sonrasında yine Linux çekirdeği üzerinde devam edeceğim. Belki bir gün yine Google ile görüşebiliriz :).

Dublin'de 2 gece kaldım ve çok gezemedim. Bir dahaki sefere daha fazla kalabilirim diye düşünüyorum. Dublin'de çektiğim fotoğraflar için buraya bakabilirsiniz.

25 Nisan 2015 Cumartesi

Linux Stajı Sonucunda


12 Mart sonunda Outreachy (OPW) kış dönemi stajları sona erdi. Ben bu süreçte bellek yönetiminde, THP (transparent huge page) kodları üzerinde çalıştım. Birlikte çalıştığım danışmanımın istersen bir süre daha birlikte çalışmaya devam edebiliriz demesiyle şimdi hala devam ediyorum :).

Staj sürecinde sadece okunur sayfalar, sıfır içerikli sayfalar (zero page, bellekte henüz eşleme yapılmamış sadece okuma isteği almış ve veri içermeyen sayfa) ve swap cache üzerinde çalıştım. Swapteki veriler için birini stajdayken diğeri stajdan sonra olmak üzere iki yama hazırladım. İkisininde ortak yanı do_swap_page kısmında takılıyor olmaları ^_^. Sistem bazen askıda kalıyor, bazen boot aşamasında bile bir panik oluyor gibi problemleri var hala. Koddaki sayaçların değerini daha iyi görebilmek için tracepoint yazdım. Tracepointi de ayrı bir yama olarak göndereceğiz. Askıda kalma problemleri için en iyi yöntemler ise serial console ya da netconsole kullanmak. Geçen gün Sarah Sharp'ın günlüğüne bakarken burada bir netconsole yazısı gördüm :). Askıda kalma olayı genelde spinlocklarda bir hata yaptıysak oluşuyor.

Outreachy'de, Linux Vakfı kendi stajerlerini 5 dakikalık kısa konuşma yapmak için Linuxcon'a davet ediyor. Ben Dublin'de olana katılacağım, Seattle'da olan biraz fazla uzak. Zaten bu ara hangi etkinliğe gitmek istesem hep Dublin'e denk geliyor, aslında ben mümkün olduğunca başka şehirler seçmeye çalışıyorum :).

Nisan başında lwn.net'te stajımla ilgili bir yazı yayınlayacaktık, yazının taslağı hazır, sanırım swaplerle olan işler bittikten sonra onları da ekleyip yayınlayacağız.

Bu staja alınmam benim için biraz sürpriz gibi oldu. Necdet hocanın hadi Ebru başvursana demesiyle başvurdum ve çok iyi oldu, çok da güzel oldu :).

Mezuniyetimden beri evden çalışıyorum, bu biraz değişik oldu. Muhtemelen bir ay daha evdeyim, sonra bir süre çekirdeğe ara verip başka işlere bakıp, sonrasında tekrar döneceğim :). Çekirdek üzerinde çalışmanın diğer alanlara göre daha fazla dikkat gerektirdiğini düşünüyorum. Çünkü bir yerde hata yaparsam o değişikliği geri almak daha uzun sürüyor, daha fazla şeyi kontrol etmem gerekiyor.

Staj sürecimde işini çok iyi yapan insanlarla birlikte çalıştım. Rik, 12 senedir Linux üzerinde çalışıyor. Bunun ilk duyduğumda bir yutkunma .. :).

Aslında üniversiteye başladığımdan beri hep işini çok iyi yapan, hayran olduğum insanlarla bir aradayım. "Harika insanlarla birlikte çalıştım" diyebilmek, bu hayattaki en güzel şeyler arasında ilk sıralarda yer alır. Çomü'de bilgi işleme gitmeye başladığımdan beri ben de bu sözü söyleyebiliyorum ve iş hayatında da böyle devam eder diye ümit ediyorum :).

17 Nisan 2015 Cuma

Linux Çekirdeğine Tracepoint Eklemek

Linux kaynak kodunda değişiklik yaptıktan sonra, bunları izlemek için farklı yollar var. Ben henüz çok değişik bir şey kullanmadım. Bu zamana kadar hep printk ile kern.log'a aktarıp, sonra grep, wc, tailsplit gibi komutlarla inceleme yapıyordum. Aslında çok farklı şeyler kullanırım sanmıştım :) ama danışmanım ilk olarak bu yöntemi önerdi.

kern.log'u incelemek sandığım kadar rahat olmuyor, her adımda kodun patlamadığından emin olmalıyım. Bu yüzden bir sürü şey yazdırıyorum, gerçi panik olduğunda otomatik olarak loglara düşüyor ama bazı askıda kalma durumlarında düşmeyedebilir. Birde her testten sonra log dosyasını boşaltıyorum sonra içinden bir şeyler parse etmek zorlaşıyor, sadece 1 test için dosya boyutunun 15M olduğunu hatırlıyorum. kern.log'u boşaltmak için bir yöntem olarak "sudo tee /var/log/kern.log < /dev/null", bunu kullanabiliriz. Hiç boşaltmadan test yapmaya devam ettiğimde dosya boyutu .. ^_^. Elbette inceleme yapılamayacak kadar büyük oluyor diye bir düşüncem yok ama zorlaştırmasak iyi olur.

Uzunca bir süredir yaptığım değişikliklerde beklenmedik sonuçlar görüyorum, aslında beklenmedik sonuçlar görmek elbette en beklendik şey :P, ilk zamanlar test yaparken her testte farklı bir sonuç görürdüm. Danışmanımın emin misin bunu gördüğüne, o zaman şunu da ekle demesine neden olmuşumdur, sonra başka bir testte ben yanlış bakmışım problem o değilmiş şeklinde döndüğüm çok olmuştur :). Ancak bu sefer öyle olmadı, ben uzunca bir süre hep aynı beklenmedik sonucu aldım. Bu durumda oluşabilecek ihtimaller, 1- ben yanlış bakıyorum, 2- pteleri swapten çektiğim halde hala bir şeyler onların swapte gibi loglanmasına neden oluyor, bunun nedeni belleği mantıklı kullanmak ya da tekrar swape gitmesi gerekirse daha az işlem yapmak istemeleri olabilir.

Test yaparken 800M'lık verinin üzerindeki değişimlere bakıyorum, büyük sayfalar 2M olarak tutuluyor. Tek bir büyük sayfa için 512 kere (normal sayfalar 4kB) döngü yapılıyor, benim de her döngüde 15 satıra yakın yazdırdığımı düşünürsek, bu durumda loglarda gözümden bir şey kaçmamıştır demek pek mümkün değil :). İşte tam bu gibi problemler için tracepoint'ler var.  Tracepoint eklediğimiz her fonksiyon için bir kez çalışıyor, aslında değişkenlerin son değerini, kodun sonuna printk ekleyerek de yazdırabiliriz. Ancak bu yöntem boş yere kern.log'u dolduruyor ve kendi testlerimiz için eklediğimiz printk'lar ile birlikte upstream'e yama gönderemeyiz zaten, yani göndermesek iyi olur :). Tracepointler; printk ekledim, eklemeyi unuttum (bir daha derle), upstreame göndermeden önce printk'ları kaldır bir daha derle - test et gibi şeyleri önlüyor. Tracepoint kodu yazıyoruz ve bir kere derliyoruz, sonra eğer o değişkenlerin değerine bakmak istersek perf aracı ile testleri çalıştırıyoruz ve değerleri görüyoruz :).

Tracepoint Nasıl Tanımlanır?

Daha önceden tanımlanmış tracepoint kodlarını inceleyebiliriz. Birde lwn.net'te çok açık anlatan yazılar var. Örneğin vmscan.c'deki birkaç fonksiyon için tracepoint ekleyeceğiz. Bunun için  include/trace/events/'de vmscan.h dosyası oluşturmalıyız. Tracepoint yazmak için yapmamız gerekenler: 1) temel tanımlamaları yapmak, 2) TRACE_EVENT() tanımlamak, 3) TRACE_EVENT içerisinde belirttiğimiz fonksiyonu kaynak kodda çağırmak.

#undef TRACE_SYSTEM
#define TRACE_SYSTEM vmscan

#if !defined(_TRACE_VMSCAN_H) || defined(TRACE_HEADER_MULTI_READ)
#define _TRACE_VMSCAN_H

TRACE_EVENT(....
                             .....
);

#endif /* _TRACE_VMSCAN_H */
#include <trace/define_trace.h>

Şimdi TRACE_EVENT() içeriğini tanımlayalım:
TRACE_EVENT(name, proto, args, struct, assign, print)
name: Kaynak kod içerisinde çağırılacak fonksiyonun adı.
proto: Fonksiyon için prototip.
arg: Fonksiyonun alacağı değişkenler.
struct: Tracepoint içine geçen verilerin depolanması için yapı.
assign: Değişken ataması yapmak için kullanılıyor.
print: Değişkenleri yazdırmak için kullanılıyor.

Yazdırmak istediğimiz değişkenler sadece struct shrinker *shr ve unsigned long lru_pgs değişkenleri olsun:

TRACE_EVENT(mm_shrink_slab_start,
    /* proto */
    TP_PROTO(struct shrinker *shr, unsigned long lru_pgs),
    
    /* arg */
    TP_ARGS(shr, lru_pgs),

   /* struct */
    TP_STRUCT__entry(
        __field(struct shrinker *, shr)
        __field(unsigned long, lru_pgs)
    ),

    /* assign */
    TP_fast_assign(
        __entry->shr = shr;
        __entry->lru_pgs = lru_pgs;
     ),

     /* print */
     TP_printk("shr = %p,  lru_pgs = %ld",
                       __entry->shrink,
                       __entry->lru_pgs)
);

TRACE_EVENT içerisinde mm_shrink_slab_start şeklinde belirttiğimiz fonksiyonu, vmscan.c dosyasından, önüne trace_ ekleyerek bu şekilde çağırıyoruz: trace_mm_shrink_slab_start(shr, lru_pgs); Bu değişkenler için sırasıyla proto, arg, struct ve assing'ı tanımladık. Daha sonrasında print ile yazdırma kısmını ekledik.

vmscan.h dosyasının tüm içeriğine buradan bakabilirsiniz. Dosya içerisinde event_class, define_event gibi tracepoint'leri gruplayarak tekrara düşmeyi önleyen makrolar kullanılmış. Ben henüz bunlara gerek duymadım. Tracepoint kullanmak için yukarıda belirttiğim 3 temel maddeyi yapmak yeterli.

                   http://lwn.net/Articles/379903/