Üreticilerin İş Takvimi ve Yöneticilerin İş Takvimi

Paul Graham'ın Temmuz 2009 tarihli bir makalesinin Türkçe çevirisi.

Uzun zamandır acısını çektiğim bir konu. Ana dilinde okumak isteyenler için Türkçe'ye çevirdim. Buyrun, afiyet olsun:

Üreticilerin İş Takvimi ve Yöneticilerin İş Takvimi
Temmuz 2009

Programcıların toplantıları sevmemesinin bir nedeni de onların diğer insanlardan farkli bir iş takviminde çalışmasıdır. Toplantıların onlara maliyeti daha yüksektir.

Benim "üreticilerin iş takvimi" ve "yöneticilerin iş takvimi" olarak adlandirdigim iki tür çalışma saati düzeni var. Yöneticilerin iş takvimleri patronlar içindir. Bir günün saatlik parçalara bölündüğü geleneksel bir randevu sistemi içerir. İsterseniz bir kaç saati tek iş için gruplayabilirsiniz fakat çalıştığınız işi ontanimli olarak her saat değiştirirsiniz.

Bu yöntemi kullandığınız zaman, birileriyle görüşmek sadece pratik bir problemdir. Takvimde boş bir saat bulur, orayı dolu olarak işaretler ve bitirirsiniz.

En güçlü insanlar yönetici iş takviminde çalışırlar. Bu, emir verme iş takvimidir. Fakat programcılar ve yazarlar gibi iş yapan insanlar arasında zamanı kullanmanın başka bir yöntemi daha vardır. Onlar zamanlarını, genellikle yarım günlük birimlere ayırarak kullanmayı tercih ederler. Saatlik birimlerle program yazamazsınız. Bu, ancak başlamak için gereken süredir.

Üretici iş takviminde çalışıyorsanız toplantılar tam bir faciadır. Tek bir toplantı tüm öğleden sonrayı iş yapılamayacak iki parçaya bölerek uçurabilir. Üstüne toplantıya gitmeyi hatırmalanız da gerekir. Bu, yönetici iş takviminde çalışanlar için sorun değildir. Her zaman bir sonraki saat için sırada olan yani bir iş vardır, tek soru ne olduğudur. Fakat üretici iş takviminde, bir toplantı olduğu zaman, bir de onu hatırlamak zorundadırlar.

Üretici iş takviminde çalışanlar için toplantılar istisna fırlatmak gibidir. Bu sadece bir işten diğerine geçmenize neden olmaz, çalıştığınız kipi de değiştirir.

Bir toplantının bazen bütün bir günü etkilediğini farkettim. Bir toplantı, sabahı ya da öğleden sonrayı bölerek genellikle en az yarım günü yer. Fakat ek olarak bazen kademeli bir etkisi olur. Eğer öğleden sonranın bölüneceğini biliyorsam sabahları da işe istekle başlayacak hevesim olmaz. Bunun aşırı duygusal gibi göründüğünü biliyorum ama bir üretici iseniz kendi durumunuzu düşünün. Tüm günün, hiç toplantı olmadan çalışmak için serbest olması sizi heyecanlandırmaz mı? Böyle olmadığında içinizde bir sıkıntı olur. İddalı projeler tanım olarak sizin kapasitenizin sınırlarındadır. Hevesinizdeki küçük bir azalma onları öldürmek için yeterlidir.

Her takvim sistemi kendi başına gayet güzel çalışır. Sorunlar bu iki takvim sistemi birbirleri ile karşılaştıklarında ortaya çıkar. En güçlü insanlar yöneticilerin iş takviminde çalıştıkları için isterlerse diğerlerini kendi düzenlerine uymaya zorlayabilirler. Fakat daha zekice olanları, eğer kendileri için çalışan insanaların calışabilmek için uzun aralıklara ihtiyaçları olduğunu biliyorlarsa kendilerini frenlerler.

Bizim durumumuz alışılmadık bir durumdur. Neredeyse tüm yatırımcılar (bildiğim tüm risk sermayedarları dahil) yönetici iş takviminde çalışırlar. Fakat "Y Combinator" üretici iş takviminde çalışır. Rtm, Trevor ve ben de zaten öyle çalışıyorduk. Genellikle Jessica da öyle çünkü o da bizimle uyumlu olmalıydı.

Bizimki gibi şirketler artarsa şaşırmayacağım. Kurucuların artan şekilde yöneticiye dönüşmeye direneceği ya da en azından geciktireceğini düşünüyorum. Sadece bir kaç onyıl önce kot pantolondan kumaş pantolona dönmek için direnmeye başladılar.

Biz üretici iş takvimi kullanarak bir çok yeni kurulan şirkete danışmanlık yapmayı nasıl başarıyoruz? Yönetici is takvimini taklit eden alışılmış yöntemi kullanarak: ofis saatleri. Haftada bir kaç kez ödenek sağladığımız kurucular ile görüşmek için zaman aralıkları ayarlıyorum. Bu zaman aralıklarını benim iş günümün sonunda, belirli ofis saatlerine yerleştiren bir kayıt uygulaması yazdım. Toplantılar günümün sonunda olduğu için asla günümü bölmüyorlar. (Görüşecegim insanların iş günleri benimkinden farklı zamanlarda bitiyorsa onların takvimi bölünüyor, ama görüşme isteğini onlar yaptığından dolayı, onlar için buna değse gerek.) Yoğun dönemlerde ofis saatleri bazen günü sıkıştıracak kadar uzayabiliyor ama günü sıkıştırsalar da asla bölmüyorlar.

Biz 90'larda kendi şirketimizi kurduğumuz dönemlerde günümü bölmek için başka bir numara geliştirmiştim. Akşam yemeğinden gece 3'e kadar program yazıyordum çünkü gece çalışmamı kimse bölemiyordu. Sonra sabah 11'e kadar uyuyordum ve işe gelip akşama kadar çalışıyordum, bunu "iş şeyleri" diye adlandırıyordum. O zamanlar bunu hiç bu şekilde düşünmemiştim, fakat aslında her gün iki işgünüm vardı, birisi yönetici iş takviminde ve diğeri üretici iş takviminde.

Yönetici iş takviminde çalışıyorsanız üretici iş takviminde asla yapmayı istemeyeceginiz kimi şeyleri yapabilirsiniz: kuramsal toplantılar yapabilirsiniz. Birileriyle sadece birbirinizin ne yaptığını öğrenmek için toplanabilirsiniz. Eğer takviminizde bir boşluk varsa neden olmasın? Belki de işler birilerine hiç beklemediğiniz şekilde yardım etmenizle sonuçlanabilir.

Silikon Vadisi'ndeki (ve dünyanın kalanındakı) işadamları sürekli kuramsal toplantılar yaparlar. Eğer yönetici iş takviminde çalışıyorsanız sürekli uygun şekilde boşturlar. Aralarında kullandıkları "bir kahve içelim" gibi bir belirgin bir dilleri vardır ve görüşmek için bunu sıkça kullanırlar.

Eğer üretici iş takviminde çalışıyorsanız kuramsal toplantılar son derece masraflıdır. Bizi usandırır. Herkes, diğer yatırımcılar gibi bizim yönetici iş takviminde çalıştığımızı varsayar. Bizi gerekli gördükleri insanlar ile görüştürürler ya da eposta ile bir kahve içme önerisinde bulunurlar. Bu noktada iki seçeneğimiz vardır, iki seçenek de pek iyi değildir: onlarla görüşebilir ve yarım günlük işimizden olabiliriz ya da onlarla görüşmemeye çalışır ve muhtemelen onları gocundururuz.

Bu güne kadar sorunun kaynağı hakkında kafamız net değildi. Bunu, ya takvimimizi fırlatıp atmak zorundaymışız ya da insanları kırmamız gerekiyor gibi ele almıştık. Fakat artık ne olup bittiğini biliyorum, belki de bir üçüncü seçenek vardır: iki farklı iş takvimini anlatan bir şeyler yazmak. Belki sonunda, yönetici iş takvimi ile üretici iş takvimi arasındaki çakısma daha çok anlaşılır ve zamanla daha az sorun olmaya başlar.

Üretici iş takviminde olan bizler uzlaşmaya istekliyiz. Belirli miktarda toplantılara girmemiz gerektiğini biliyoruz. Yönetici iş takviminde çalışanlardan tüm istediğimiz bu bedeli anlamaları.


Sam Altman, Trevor Blackwell, Paul Buchheit, Jessica Livingston ve Robert Morris'e bunun taslaklarını okudukları için teşekkürler.

Paul Graham

The Other Half of "Artists Ship"

Paul Graham'in bir makalesinden alinti:

Buyuk sirketler ile sifirdan baslayan sirketler arasindaki farklardan birisi buyuk sirketlerin kendilerini hatalardan korumak icin surec gelistirmesidir. Sifirdan baslayan sirketler yeni yurumeye baslayan cocuklar gibi surekli oraya buraya carpip duserler. Buyuk sirketler daha tedbirlidir.

Bir kurulusta zamanla biriken denetimler kaynagini gecmis felaketlerden alan bir ogrenme seklidir. Ornegin batmakta olan bir bayi ile anlasma imzalayan bir sirket, musterilerine mallari teslim edemezse tum bayileri icin odeme gucu olduguna dair bir belge saglamayi zorunlu tutabilir.

Sirketler buyudukce gerek felaketlerden edindikleri deneyimler ile gerekse daha buyuk sirketlerden aldiklari yeni calisanlarin getirdigi deneyimler ile denetimlerinin sayisi surekli artar.

Hatalardan ogrenmek kuruluslarin dogasinda vardir. Asil sorun yeni denetimler oneren insanlarin neredeyse hic bir zaman denetimin kendi maliyetini dusunmemeleridir.

Her denetimin bir maliyeti vardir. Ornegin bayilerin odeme guclerini dogrulamalari durumunu ele alalim. Bu saf ongoru degil mi? Fakat aslinda bunun azimsanmayacak bir maliyeti olabilir. Her iki tarafta da odeme gucu icin kanitlari hazirlayan ve inceleyenler insanlarin zaman masrafi oldukca net. Fakat asil maliyet gormediginiz yerlerdedir: en iyi bayi olabilecek sirket teklif vermeyebilir, onaylanmak icin bosa caba harcamak istemiyorlardir. Ya da odeme gucu belirlenen esik degerin altinda kalan en iyi muhtemel bayi, ne de olsa belirlenen esik degerini yukseltmenin gorunen bir maliyeti yok.

Kurumlarda ne zaman birisi yeni bir denetim onerse faydalarinin yaninda zararlarini aciklamali. Bu ust-denetim, analizinin ne kadar iyi yapildigindan bagimsiz olarak, denetimin ayni zamanda bir maliyeti oldugunu da hatirlatacak ve bunu arastirmaya itecektir.

...

Yillardir kendi calistigim sirkette destekledigim yontemler nedeniyle cevremdekiler tarafindan duzen karsiti birisi, bir anarsist olarak anildim. Yazdigimiz her kural ve yonerge maddesinin zararlarini farkli sekillerde dile getirmeye calistim. Bunca zamandir sanirim hic bir cabam anlatmak istediklerim konusunda bu yazi kadar net olamadi. Dile getirdiklerimin bir kismini Paul Graham bu yazida cok net bir dille ele almis. Uzgunum ve mutluyum.

PHP Oturumlari Uzerine Kisa(!) Bir Hikaye

Son zamanlarda Zeitin'de gelistirdigimiz bir goruntu yayin aracinin arayuzunu PHP ile yazmayi tercih ettik. Bir canli yayin uygulamasi. Herhangi bir internet kamerasindan (webcam) aldigimiz goruntuyu canli olarak yayinlayabiliyoruz. Ornegi icin bizim sirketin sitesine bakabilirsiniz, ofisimiz 24 saat hizmetinizde.





Yayin yapacak olan kisi kamera takili bir bilgisayar ile yayin arayuzune giriyor ve bir flash uygulamasi araciligiyla yayin hemen basliyor. Biz bu is icin sirketteki eski dizustu bilgisayarlardan birisine bir kamera bagladik, yayin sayfasini actik, giris yaptik ve dizustu bilgisayari ofiste uygun dolabin uzerine tozlanmaya terkettik.


Kameranin surucusu daha sorunsuz calistigi icin dizustune Windows kurup oldugu yerden tekrar indirmemek icin de uzerine bir vnc sunucu kurduk. Oldu, calisti. Ne de olsa tum isi bir internet sayfasini acik tutmak, gunlerdir basariyla yapiyor bunu.

Ancak yayincida cok uzun sure (bir kac gun/hafta) acik kalan flash uygulamasi bir sure sonra tarayiciyi yoruyor. Bunun icin yayin sayfasi saatte bir kendisini yeniliyor (bildiginiz META tag'i ile). Yayincinin oturumunu unutmamasi ve her yenilenmesinde giris ekranina geri donmemesi icin de PHP oturumuna yayincinin bilgisini kaydettik.

Sistemi kurduk, her sey bir kac hafta gayet guzel calisti, gun gelip de uygulamaya yeni ozellikler eklememiz gerektiginde giris mekanizmasini da biraz degistirdik. Ancak bu degisiklikten sonra yayincinin oturumu her 4-5 saatte bir zaman asimina ugramaya basladi.

Hatanin nedenini anlamayinca git teslimleri uzerinden tum yamalari satir satir inceledik. Hatanin nedenini gene bulamadik. Haftalarca calisan kod durduk yerde calismaz olmustu ve ortada hataya neden olacak tek satir yoktu.



Artik kodda hata olmadigindan emindik (oysa onca zaman hatanin kodda oldugundan emin gibiydik), kod disinda bizi etkileyebilecek bilesenleri incelemeye basladik. Apache ayarlari, php.ini, yayincidaki cerezlerle (Cookie'ler) ilgili ayarlar...

Sorun uzerinde 2-3 kisi dusundugumuz halde gunlerce nedenini bulamadik. Sonunda PHP'nin oturumlari nasil yonettigini anlamak icin php.net'teki ilgili sayfalari okurken uc adet calisma zamani yapilandirmasi dikkatimi cekti.

Birisi session.cache_expire degiskeni idi. Bir oturumun ne kadar hayatta kalacagini belirtiyordu. Ontanimli degeri 3 saat idi ama bizim 30 dakikada bir kendini yenileyen sayfa oturumunu duzenli olarak 3 saat'te bir unutmuyordu, bazen 4-5 saati bile geciyordu. Hem yarim satte bir yeniden baslayan oturum neden zaman asimina ugrasindi ki.

Diger iki degiskeni pek anlamlandiramadim: session.gc_divisor ve session.gc_probability. Bu degiskenler oturumlari temizleme isleminin kac oturum baslatma (session_start()) basina yapilacagini belirtiyordu. Bu pek makul gelmedi.

PHP arka planda calisan ve surekli ayakta duran bir hizmete (daemon) sahip degil. Sonucta PHP, istekler geldikce (sayfalar acildikca) Apache tarafindan cagrilan bir uygulamadan ibaretti. Dolayisiyla zaman asimi gibi belli surelerde bir yerine getirmesi gereken gorevlerin zamanlamasi icin ince cozumler gerektiriyor.

PHP gelistiricileri oturumlarin zaman asimina ugratmak icin her session_start() isleminde %1 ihtimalle temizlik yapmayi uygun bulmuslar. Aslinda cok cakma bir cozum ama anlasilan pratikte ihtiyaci karsiliyor ki yillardir farkina bile varmamisim.

Bizim sistemimizde ise calisan tek site bahsettigim yayinci sayfasi ve oturum kullanmayan izleyici sayfalarindan ibaret diyebilirim. Bu durumda session_start() cagri sayimiz da her yarim saatte sadece "bir". Dolayisiyla 3 saat gectikten sonra oturumun kapanma olasiligi her yarim saatte %1.

Bunlari anlayinca aralarda gordugumuz 4-5 saat boyunca zaman asimina ugramama durumunu aciklayabildim. Kucuk bir hesapla oturumun 3 saatlik zaman asimi sonrasinda her yarim saat icin sadece 1/100 ihtimal ile temizlenecegini dusunursek, diyelim ki %1 ihtimal 50. denemede denk geldi. Bu durumda sistemin 30dk*50 = 25saat kadar dayanabilmesi gerekirdi. Ancak sistemin en cok 5-6 saat kadar dayandigini biliyordum.

PHP'nin oturum degiskenlerini /tmp altinda bir dosyada tuttugunu bilyordum, biraz inceleyince buldum ki benim kullandigim Debian Lenny sistemde aslinda /var/lib/php5 dizininde duruyordu. (PHP'yi hic elle derlemedigim icin kullandigi dizinlerin yerine pek asina degilim.)

Uzun bir sure /var/lib/php5'i nereden hatirladigimi cikartamadim. Sonra surekli olarak /var/log/messages'da bununla ilgili kayitlari gordugumu hatirlayabildim:

Jun 2 21:39:01 farmer /USR/SBIN/CRON[25973]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -n 200 -r -0 rm)

Cron'dan yarim saatte bir calisan bu betik /var/lib/php5/ altinda son degisiklik tarihi belli sureden daha eski olan dosyalari temizliyordu.

/usr/lib/php5/maxlifetime da bir bash betigiydi ve yaptigi is de /etc/php5/*/php.ini dosyalarini okuyarak aralarinda en uzun zaman asimi suresini donmekti. PHP'den boyle cakma bir cozum beklemiyordum dogrusu. Gerci bu cozumu belki de Debian paketcileri yapmistir, pesine dusup incelemedim.

/usr/lib/php5/maxlifetime betigi de benim sistemimde 24 degeri donuyordu. Crondan da 30 dakikada bir calistigina gore en kotu durumda 24+30=54dk kadar gecikme ile tum oturumlari temizleyecekti.

Bu durum galiba bizim gibi session_start()'i seyrek araliklar ile cagiranlar icin dusunulmustu ve aslinda daha onceki hesabimin sonucunda bulabildigim gibi benim oturumunun asla bir gunu bulmamasini acikliyordu.

Oturumum zaman asimi suresi geldikten sonra en kotu ihtimal ile 54 dakika sonra silinecekti.

Geriye cozemedigim tek soru kaldi: yarim saatte bir session_start() cagiriyorsam zaman asimi suresi de devamli olarak yarim saat otelenecek ve asla zaman asimina ugramayacakti. Ancak kodlarda hata olmadigi halde 3 saat sonra sonra oturum kapaniyordu.

Neyse ki eldeki verilerle cozumu bulmam zor olmadi. PHP oturumlarini /var/lib/php5 dizininde sakliyordu ve syslog'daki saitirdan anladigim kadariyla oturumlari silmek icin de dosya sisteminin tuttugu degisiklik zamani bilgisinden faydalaniyordu. Bu durumda kurdugum oturumun degisiklik zamanini izleyerek sorunun nedenini bulabilirdim.

Oncelikle oturumu baslattim ve oturumumun oldugu dosyayi buldum. Allah'tan PHP oturumlari karmasik sekillerde saklamiyordu:

bekir@farmer:/var/lib/php5$ sudo cat /sess_76995dd9473835f06e03d0da59275eef
publisher|s:6:"kaplan";token|s:9:sts18683140";

Sonra stat komutu ile benim oturum dosyamin bilgilerine baktim, asagida gordugunuz "Change:" yazan kisim dosyada en son ne zaman degisiklik yapildigini gosteriyor.

bekir@farmer:/var/lib/php5$ sudo stat ./sess_76995dd9473835f06e03d0da59275eef
File: `./sess_76995dd9473835f06e03d0da59275eef'
Size: 45 Blocks: 8 IO Block: 4096 regular file
Device: 904h/2308d Inode: 15705843 Links: 1
Access: (0600/-rw-------) Uid: ( 33/www-data) Gid: ( 33/www-data)
Access: 2009-06-03 00:37:44.000000000 +0300
Modify: 2009-06-03 00:37:26.000000000 +0300
Change: 2009-06-03 00:37:26.000000000 +0300

PHP oturumlari temizlerken sadece degisiklik zamanina baktigi icin artik tum is sadece bu dosyanin son degistigi zaman ("Change:") degerinin ne zaman kuruldugunu kesfetmeye kalmisti.

Bir kac deneme yaptim. Oturum olustugunda dogal olarak yukaridaki gibi bir kayit olusuyordu ancak yarim saatte bir gelen sayfa guncellemelerinde bu ozellik guncellenmiyordu. Oysa ki her seferinde session_start()'i cagiriyordu ancak dosyayi takip ettigimde sadece erisim ("Access:") zamaninin degistigini farkettim.

Yazdigimiz kodlara dondum oturumla ilgili kisimlarini tekrar okudum. Eger kurulu bir oturum varsa sayfayi kullaniciya gosteriyor ve oturum uzerinde uzerinde hic islem yapmiyorduk. Cok guzel.

Ancak oturum uzerinde islem yapmadigimiz icin PHP oturum dosyasini asla guncellemiyor ve dolayisi ile dosya sisteminedeki degisiklik zamani ("Change Time") bilgisinin guncellenmesini tetiklemiyordu.

Belkedigimin aksine session_start() oturum dosyasinin degisiklik zamanini guncellemiyordu. Aslinda yapiyi anladiktan sonra cok normal bir davranis oldugunu anlayabiliyorum.

Tum bu incelemelerden sonra koda tek satir ekleyerek uyguladigim cozum her sayfa acilisinda oturum olsa da sadece bir oturum degiskenine atama yapmak oldu.

Gunlerdir aradigimiz sorunun cozumu soyle tek satir imis:

$_SESSION["reset_session_timeout_hack"] = 1;

Sistem su anda iki gundur sorunsuz calisiyor. Tum yazdiklarimi buldugum gece php.net sitesini gezip hatayi ayiklamak 2 saat kadar vaktimi almisti ama bu yaziyi hazirlamak icin 6 saat kadar caba harcadim, hala bir yerlerde ciddi yanlislik yapiyorum sanirim.

Kod gozden gecirme sureci ve GvR amcanin katkilari

Gecen gun Google App Engine ile bir seyler denerken farkettim ki sundugu SDK'de bulunan appcfg.py ile elimizdeki kodu teslim etmeden once yaptigimiz degisikliklere gozatma imkanimiz yok. Kodlarimizi svn gibi bir surum denetim dizgesi kullanmamiz gerekiyormus. oysa app engine'deki surum numaralarini gorunce sonuncu ve simdiki araasindaki degisikliklere bakabileceimi sanmistim.

google'da "google app engine pre commit diff" gibi bir arama yapinca karsima http://code.google.com/p/rietveld/ geldi. parkyeri'nde zamanla ve acilar cekerek kesfettigimiz kod gozden gecirme surecinin cok benzerini google'da da kullaniyorlarmis ve Guido van Rossum(GvR - python'un yaraticisi ve hala yon vericisi, etkin kod gozden gecirici) amcamiz google'a girdikten sonra ilk proje olarak bu sureci iyilestirmek icin kollari sivamis, mondrian diye bir arac yazmis.

bizim mevcut yapimiz asagidaki gibi ve google'daki ile fazlasiyla benzerlik gosteriyor, meraklilari icin parantez icerisine kendi kullandigim araclari yazdim:

1. bir kisigereken kodu yazar (emacs ... | vim ...)


2. yama uretir (svn diff > ticket_no.patch)


3. ilgili gelistirme grubuna gozden gecirme icin eposta atar (mutt -a ticket_no.patch hede@parkyeri.com)


4. gruptan bir kisi kendi deposuna yamayi uygular (patch -p0 < ticket_no.patch)


5. kodu inceler (emacs ... | vim ...)


6. kodu inceleyen kisi epostadaki yama icerisine notlarini yazar ve kodun yazarina gonderir, (mutt)
   (ya da benim genelde yaptigim gibi yazan adam ile dogrudan konusarak sosyal yollarla da cozebilir (finch, konusma))


7. kodu ilk yazan kisi kodu tekrar duzenler ve tekrar yama uretip gonderir (svn diff ... , mutt -a ...)


8. bu surec, kodu gozden geciren kisi "eline saglik teslim edebilirsin"(este) (Enver'den bize miras olarak kaldi) diyene kadar tekrarlar (bazen yamalarimiza changelog eklemedigimiz icin "este" yerine "changelog ekleyip teslim edebilirsin[cete]" cevabi da gelebilir)


9. son olarak da "este" alan kodlarimizi teslim ederiz (svn commit)

Kullandigim araclar basit gozukebilir, ama genel olarak islerini guzel yapan araclar ve cok da fazla dis yardima ihtiyac kalmiyor. Genellikle kodlarimizi ssh ile eristigimiz uzaktaki makinalar uzerinde gelistirdigimiz icin diger gelistiricilerin ev dizinlerinden onlarin neler yaptigini izleyebiliyoruz ve yama alisverisi eposta uzerinden olmak zorunda kalmiyor hatta bir cok durumda yama alisverisi bile olmuyor, girip diger bir gelistiricinin proje dizininde "svn diff | vim -" diyerek kodlari okuyabiliyorum, ancak bunlar gorece kucuk olmamizin getirileri.

Kucuk projelerde artik gozden gecirme surecimiz dahi olmuyor, degisikliklerin takibi ve teslim sonrasi gozden gecirme icin svn teslim epostalari, Trac ve eklentileri yeterli.

Gozden gecirmenin onemini anlatip duran ve bunu python gibi buyuk bir projeyi yonettigi icin yapmak da zorunda olan GvR amcamiz zamaninda ortaya koydugu mondrian'i fazla google bagimli oldugu icin (perforce ve bigtable gibi bagimliliklar yuzunden) acik kaynak haline getirememis, ancak daha sonra Rietveld adiyla acik kaynak olarak da yayinlamis ve diger acik kaynak projelerin kullanimina CodeReview adiyla google app engine uzerinden acmis.

Aracin (rietveld) ornek kullanimi burada.

Yeni bisiklet, Sariyer

Uzun zamandir bisiklet alma hevesiyle ortalarda dolanip duruyordum. Samet ve
Yigit ile Hasim-Iscan Gecidine gidip oradaki vahim durumu gordukten sonra
sonunda cuma gunu Samet ile Velespit'ten son model bisikletimi gonul rahatligi
ile aldim.

Ayni gece geziye cikayim bogaz sahillerinde gezineyim dedim. Saat 02:00'de
evden ciktim, Sisli'den Taksim'e ve oradan Besiktas uzerinden sahilden devam
ettim. Eglence mekanlarinin onu oldukca kalabalikti. Sahilden devam ettim.
Sahil seridinde gece fareler ve kopekler cirit atiyormus. Evet evet, bir suru
boyut ve cesitte fare gordum, hatta bir kismiyla sahilde birlikte yol aldik.

Ortakoy, Bebek, Istinye derken Tarabyaya geldim, gecenin 3'unde hala balik
tutan bir suru insan vardi. Oralardaki bir tekel bayine ugradim ama param
olmadigi icin neredeyse su alamiyordum. Neyseki tekelci sadece 1.5 litre suyu
bankamatikten cekti de susuz kalmadim, Sariyer'e cok fazla kalmadigini
ogrendim, yola devam ettim.

Dolunay sayesinde sahilin isiklandirilmamis kisimlari da karanlik degildi ama
kopekler zaman zaman tehlike arzedebiliyordu.

Saat 3:40'da Sariyer'e vardim ve oradaki bankadan para cekip gerisin geri
tekelciye dondum; Cokonat, Hobby ve yarim litrelik bir su daha aldim, bu kez
para ile odedim.

Donuste kopekler ve fareler disinda sahildeki bos bira siselerine de dikket
etmek gerekti. Ozellikle Rumeli Hisari'ni gectikten sonraki park baya demlenme
mekani haline gelmis.

Bebek'e geligimde bufe gordum dayanamadim bir sosisli yemek icin durdum, bu
sirada sabah ezani okunmaya basladi.

Bebek'ten cikip ortakoye gelirken gunun aydinlanmaya baslamasiyla sahilde balik
tutmaya gelmis oldukca yogun (en azindan o saatler icin) bir kalabalik vardi.

Ortakoye gelmeden ictigim sular etkisini gosterinde bir benzincide mola vermek
zorunda kaldim, mola vermisken iki de King Top alip icinden cikan alti
cikolatayi mideye indirdim.

Ortakoyde hayatimin en tezat goruntulerinden biriyle karsilastim, eglence
mekanlarindan cikip, arabalarini getiren valeye bahsis veren insanlarin tam
yanindaki copu kurcalayan bir amca vardi, cok fotograflik bir andi.

Goruntuye cok da takilamadim cunku eglence sonrasi kafayi bulan insanlarin
kirdigini sandigim siselerin cam parcalarindan kacinmaya calisiyordum.

Ortakoye geldigimdehenuz gunes'in dogmasina vakit olsa da artik hava
aydinlanmaya baslamisti. Gunes dogmadan Besiktas Stadi'nin yanindaki yokusu
tirmanmayi tamamlayabildim

Mecidiyekoye geldigimde saat 06:00 olmustu, hava iyiden iyiye aydinlanmisti ama
gunes hala ortalarda gozukmuyordu.

Tercih ettigimiz araclar

Az once Serdar ile konusurken birlikte calistigimiz sirketlerdeki calisanlarin bize gore ne kadar farkli araclar kullandigindan bahsediyorduk. "Abi HTTP basliklarini gezginden degistirebileceklerini bile bilmiyorlar" diye soze girmisti Serdar, sonrasinda da bizim IE ozurlu oldugumuzdan devam ettik. Sirkette pek windows makinalarla ugrasmayi tercih etmedigimiz icin urunlerimizi bazen IE ile test etmekte zorlaniyoruz.

Yazdigimiz uygulamalar unix turevi sunucularda kostugu icin arkauçlarda genellikle pek sorunumuz olmuyor. Ama web uzerinden erisilen kisimlar icin IE ve Safari testleri yapmak zorunda kaliyoruz. Bu tur testeri genellikle sirket icerisinden baglandigimiz Windows ve Mac sunucular uzerinden yapiyoruz, sagolsunlar.

Parkyeri'nde calisan profilimizden dolayi genellikle acik kaynakli araclar kullanmayi tercih ediyoruz. Aslinda pek de bilincli bir tercih degil; ama para verip uygulama satin alip, uzerinde gelistirme yapmaya alismis insanlardan olusan bir kadroya sahip degiliz.

Su anda ilk geldigimden oldukca farkli ve daha iyi bir konumdayiz, biraz kalabaliklastik, ve kendi adima birlikte calismaktan daha cok zevk alacagim insanlar geliyor Parkyeri'ne. Zamanla degisimimizin kullandigimiz araclara yansiyan bir kismini asagida gorebilirsiniz.

Parkyeri'ne ilk geldigimde benim icin cok yeni olan ama hayatimi degistiren bir cok araci tanimak zorunda kalmistim, hayatimi etkileyenlerden aklima gelenler sirasi ile sunlar:

 - debian ve gnome: Sirketteki tum masauslerinde debian calisiyordu ve herkes gnome kullaniyordu ve ben o gune kadar hep KDE kullanagelmistim. Insanlarin neden Gnome tercih ettigini Gurkan Aslan'dan "masaustu egitimi" alincaya kadar pek de anlamamistim. Gurkan daha sonra Debbie ve Ian'i, RMS'in kim oldugunu, GNU'nun ne demek oldugunu baska bir egitimde anlatmisti. Guzel gunlerdi.

- ssh: Urunlerin yonetimi ile ilgilendigim ve musterilere destek verdigim gunlerde benim icin sadece sunuculara acilan kapiydi. Yerelimde nasil calisabiliyorsam uzakta da aynen calismami saglayabiliyordu, ama gene de telnet'ten sonra tum dunyam aydinlanmis gibiydi. Kimi sunuculara bir kac makina uzerinden hoplayarak gitmem gerektiginde de sorun cikmiyordu, bir sure sonra uzaktaki makinalarin portlarini yakinlara tasimayi da ogrendigimde henuz bu bilginin, kati erisim kisitlama politikalari olan musteriler icin kod gelistirirken ne kadar ise yarayabilecegine dair fikrim dahi yoktu.[ssh ile tunelleme icin link]

 - firefox: zaten kullanageldigim super arac, neresini anlatayim ki!

 - firebug: 20$ bagis yaptigim firefox eklentisi. IE de debug yapabilmek icin koskoca script debugger[] kurdugum ve her calistirmamda IE'yi donduran himbil programlar ile ugrastiktan sonra dunyayi yeniden kesfetmemi saglayan nane.

 - livehttpheaders: HTTP basliklarinda gelen giden verilere erisip uzerinde oynama yapabildiginiz super eklenti. ozellikle bizim gibi cep telefonu modeline gore farkli wap sayfalari getirecek sistemler gibi bin bir farkli baslik bilgisinin oldugu sistemler ile sik ugrasmaniz gerekiyorsa HTTP basliginda telefonu ya da baska bir uygulamayi taklit edebilmenin gucunu bilyorsunuz demektir.

 - tamperdata: bir sitenin acilisinda hangi dosyalarin yuklendigini gorebildiginiz bir grafik de sunabiliyor. urettigi grafigi biraz daha derin sekilde incelerseniz hangi JS dosyalarinin firefox tarafindan ne kadar surede ayristirildigini (parse edildigini) da cikartabiliyorsunuz. Bizim gibi masaustu uygulamasi tadinda web uygulamasi (JS kodu) gelistirmeniz gerekiyorsa eklentinin ciktisi olan grafiklerin derinlemesine incelemesi sizi guzel cozumlere goturebilir.

 - emacs: Parkyeri'ne geldikten sonra Haldun'un (Parkyeri mezunudur kendisi) ve Erhan'in gazi ile ogrendigim, genellikle icinde yasadigim, bu blog girdisini yazdigim sey! Bilgisayarimda sirasiyla XFCE, firefox ve sonra emacs acilir her ne hikmetse :) psvn gibi uzantilari (vc) ve icerisinde lisp kodlayarak ozellestirilebilir olmasi vim'den emacs'e gecmemin nedenidir. bir kez acarsiniz, icinde yasarsiniz.

 - vim: programci dostu, emacs'e gore cok hizli yuklenen gelistirme ortami. (Gerce Emacs'i sadece bir kez aciyoruz.)

 - etags: vim ve emacs kullaniyorsaniz projenizdeki dosyalarda yer alan islevleri (fonksiyonlari) tag'ledikten:

        "find . -print | etags -"

sonra, kod icerisinde gezinirken vim'de C-], emacs'de M-. tus bilesenleri ile o fonksiyonlarin tanimlandigi dosya ve satira erisebilirsiniz. "E, eclipse bunu zaten yapiyor" deyebilirsiniz ama bellekte kapladigi yeri de dusunuyorsunuz degil mi? Bu yontemde hangi dili kullandiginizin pek onemi yok.

 - screen: tum gelistirme ortamlariniz bizim gibi tamamen uzakta ise ve arkadaslarinizin tumu uygulama gelistirme sunucularina erismek icin ssh uzerinden uzaktaki vim, emacs gibi araclari kullaniyorlarsa turkiyenin altyapisina olan guvenden haberdarsinizdir. uzaktaki bir bilgisayarda kod yazarken baglanti her gittiginde kufretmek istemiyorsaniz screen kullanin. uzaktaki makinelerde .bashrc icerisine koydugum asagidaki satirlar kisisel olarak cok isime yariyor dogrusu. Konsol icin windows'daki "duraklat" (hibernate) ozelligini cagristiriyor.

        if [ "x${TERM/-w/}" == "xscreen" ]; then #sometimes it could be screen-w
                echo You are inside a screen.;
        else
                screen -Rd;
        fi

 - rcs, cvs: eskiden versiyon takibi icin bu meretleri kullanirdik. Parkyeri icerisinde cvs'imiz pek kisa omurlu oldu, rcs zamanindan gelen degisiklik bilgilerini kaybetmeden cvs gecisi yaptiktan kisa bir sure sonra da svn'e gectik. ama sistem yonetimi icin kimi yapilandirma dosyalarinin takibinde hala RCS kullandigimiz yerler de var.

 - svn: Enver'in cabalari ile eski sistemleri birakip svn'e ilk gectigimizde biraz garip gelmisti, her yeni teslimde tum projenin revizyon numarasinin yukselmesi gibi gariplikler vardi. SVN'in inceliklerini ogrenmek biraz vakit aldi. Ama ne olursa olsun sirkete ait bir projede kendi dalinizi acmak gibi bir lukse sahip olmanin anlamini ancak yasayan bilir sanirim. svn teslim epostalari ile gelistiriciler kod deposuna yaptiklarini teslim ettiginde projedeki ilgili herkes degisiklikleri aninda gorebiliyor.

 - dcl: bilet takip sistemimiz. zamaninda uzerinde degisiklik yaptigimiz bir surumunu kullaniyoruz. musterilerin ilettigi her sorun icin bilet (is havalesi) aciyoruz... Bir cok firmada bir sekilde vucut bulan bildiginiz is takip sistemi.

- webcalendar: sirket icerisinde toplanti yonetimini ve kimin ne zaman hangi ofisimizde olacagini bu uygulama ile takip ediyoruz.

- trac: kimi projelerin islerini takip ederken dcl yerine trac kullanamyi tercih ediyoruz. svn depolarimizla birlikte calisabilmasi "proje maddeleri" (biletler) ve "gelistirilen kod" arasindaki iliskiyi cok net kurabilmemizi sagliyor.

 - jmeter: uygulamanizi cok cesitli sekillerde test edebilmenizi saglayan pek esi olmayan nane. birim testlerimizi web uzerinden tetikleyen ve servislerinize ait istatistiki bilgi uretebilmenizi saglayan bir arac. yaptigi isteklerin sonuclarini sizin belirlediginiz kriterlere gore denetleyebilen, yeri gelince ciktidaki xml'i ayristirabilen, yeri gelince aldigi cevabin dogrulugunu veritabanindan deneteyebilen olcen super arac. kimi gunlerde turkiyenin hatiri sayilir kesiminin kullandigi uygulamalar gelisiriyorsaniz yuk testleri yaparken bir cok makina uzerinden paralel (dagitik) calisabilmesi de cok ise yariyor.

 - apachebench: HTTP uzerinden calisan servisleriniz icin oldukca agir yuk testlerini yapabileceginiz arac. jmeter gibi cikti uzerinde dogrulama yapamasa da basit bir kac betik ile birlikte kullandiginizda sisteminizde asiri yuk yaratmak ve etkilerini olcmek acisidan oldukca faydali.

 - postgresql: Yalan atmama gerek yok sanirim, oracle gordugumuz yere postgresql koymak icin caba harciyoruz. oracle kullanmaya mecbur kalmadikca kullanmiyoruz. Postgresql zaten yuk dengeleme, yedekli calisabilme gibi kritik uygulamalarda sart olan ozelliklere sahip. oracle'da protokollerin, isletim sisteminin ya da sitemin kendisinden kaynaklanan sinirlara dayandiginizda isin icinden cikmak icin bir oracle uzmani bulmadan edemiyorsunuz.

 - mysql: mysql uzerinde cok zamandir kosan servislerimizin milyonlarca kayda ragmen tokezlemedigini bilmek ic ferahlatiyor.

 - memcached: uyulamaniz yukleri paylastirmak icin n tane makina uzerinde kosuyorsa size gelen her istegin farkli bir fiziksel makinaya iletilmesi session kullaniminizi etkileyebilir veya agir yuk altinda veritabani islemlerinizi cache'lemeniz gerekebilir, bir suru makinada paralel calisabilen bu kucuk programcik hayat kurtarabiliyor.

Kullandigimiz araclardan ilk cirpida aklima gelenler simdilik bu kadar. Bir cok kisi icin bunlar pek bir sey ifade etmese de belki bir gun birilerinin isine yarayabilir.

Blogged with Flock

Turkiye Bilisim Etkinlikleri Takvimi

Turkiyedeki bilisim etkinliklerinden herkesin haberdar olabilmesi icin bir google takvimi olusturdum.
Sagda solda gordugum bilisim etkinliklerini bir suredir elimden geldigince bu takvime ekliyorum.

Takvimi gormek icin suna tiklayin:

Ozellikle TBD'den Dilek Kilic'in her ay attigi etkinlik epostasi ve Mustafa Akgul'un gonderdigi epostalardan ve
http://www.btetkinlik.com/,
http://www.turkbilmed.com/,
http://www.bilisimmerkezi.org/,
http://www.btetkinlik.com/
adreslerinde gordugum etkinlikleri eklemeye calsiiyorum.

Powered by ScribeFire.