nizam-ı blog

bir ara egiBlog'a biraz nizam, intizam vermek lazım.  güzel bir şeyler tasar etmek ve o tasarımı tavizsiz uygulamak lazım...

... ne var ki şu anki gidişata göre bu iş gelecek yılın işiymiş gibi duruyor.  iş dışı işlerden -amma da "iş" dedim ha!- şu sıra zamanımı sömüreni, dükkandaki dosya paylaşım sistemimin (filezilla server üstü 1-2 el yapımı uygulama) gözden geçirilmesi.  şimdilik kim neyi kaç kez indirmiş, upload yapanlar ne kadar upload yapmış, onları incelemeye çalışıyorum.  tüm server log'larını (2008 mart-bugün) bir db'ye aktarıyorum; bu şekilde her halükarda n tane log dosyasına göre daha sorgulanabilir olacak elimdeki veri.  daha ileri aşamalarda ise paylaşım sisteminde neleri tutup neleri atacağımı belirlemeye çalışacağım.

işte de bir aralık ayı klasiğiyle uğraşıyor olacağım.  dükkanın müşterilerine biraz pahalıya patlayacak bir iş :)

twitter'a fena sardırdım şu sıra.  geçen sene nisan'da başlamışım tweet'lemeye.  hatta baktım ki, yukarıda bahsettiğim işe twitter'da değineli bir yılı geçmiş (uuu, yüzkarası).  egiBlog'a eskisinden de seyrek yazıyor olmamın en temel nedeni olsa gerek twitter.

ayda bir anca

yoğunum.

öyle böyle değil, her yerden iş yağıyor.  iş yapmaktan iş yapamıyorum; araya giren ıvır zıvır şeyler yüzünden esas uğraşmam gereken ve hepsi de zaman kısıtlarına bağlı işlere eğilmek bir türlü nasip olmuyor, olamıyor.  hani iş konusunda gevşek davranan, yumurta kapıya dayanmadan harekete geçmeyen biri olsam anlayacağım ama böyle bir durum da yok.  işin boktan tarafı, temmuza kadar böyle gidecek gibi.  geçen seneki gibi saçmasapan bir zamanda tatile çıkmak durumunda kalmam umarım.  iyi blog yazısı çıkıyor böyle zamanlarda fakat bünye üzerindeki etkisini sorun siz bir de :)

bitirme projesinde test verisi üzerinde işi epeyce kolayladım.  test verisi derken hafiften istanbul'u andıran (iki bağlantıyla birbirine bağlanmış iki büyük blok) bir bağlantılar grafiği oluşturdum.  110 nokta ve bunları bağlayan 200 küsur doğru parçası duraklarımı ve yol ağını oluşturdu.

[caption id="attachment_181" align="aligncenter" width="419" caption=""test şehri""][/caption]

durak adları önce y, sonra x koordinat düzlemindeki harf alınarak elde ediliyor, örneğin şehrin kuzeybatı ucundaki durağın adı ka.  bu bağlantılar grafiğindeki yolları izleyerek 110 noktanın tamamını kapsayan 36 hat oluşturdum.

[caption id="attachment_189" align="aligncenter" width="439" caption="hat yayılımı"][/caption]

tek tek hatları vermeyeceğim, meslek sırrı :)

işin "epey kolaylanmış" kısmı aktarma hesaplamasını yapan program.  programa başlangıç ve bitiş duraklarıyla beraber maksimum aktarma sayısını girince mantıklı sonuçlar elde edebiliyorum. mesela ab noktasından maksimum 2 aktarmayla jk noktasına nasıl gidildiğini hesaplayalım:

[caption id="attachment_198" align="aligncenter" width="392" caption="hesaplanmış aktarmalar"][/caption]

ortaya çıkan seçenek ağacındaki ilk seçeneği şu şekilde dillendirebiliriz: "ab'den 00 numaralı otobüse bin. 1 durak sonra bc'de inip oradan 04 numaralı otobüse bin. 6 durak sonra jk'da in."  arada tek aktarmalı bir seçeneğin (ab'den 04 otobüsüyle 7 durak sonra jk) de bulunduğu, yani maksimum aktarma sayısından daha az aktarmaya sahip durumların da hesaplandığı görülebilir. güzel yani :)  bu yapıya seyahat süresi tahmini ile ilgili yapıyı da eklemlediğimde daha da güzel, tadından yenmeyesi bi'şey çıkacak ortaya.

yarın da dernek yönetim kurulu var ve bu yüzden ferdaanım'ın brunch'ını (so posh, ain't it?) ekiyorum.  zaten sabahın 10'unda kanlıca'da olmamı sağlayacak hızı ve gazı bulmak zor, hele bu sabah bir pazar sabahı ise.  uyuy'cam len?!

egiboy planlama teşkilatı ciddiye bindi

egiBlog'da arada bir hakkında yazılıp çizilip kafa tütsülemekten başka hiçbir işe yaramamış varsayımsal bir oluşumdur egiboy planlama teşkilatı. uygun zamanı ayırabilsem girişebileceğim işlerin bir kurumsallaşmış ve dahi yosun tutmuş bir listesi... anahtar kelime "zaman" tabii burada; devamlı yokluğunu çektiğimiz, bol bulduğumuzda da har vurup harman savurduğumuz şeylerin başında gelir. sizin için olmayabilir ama benim için fena halde öyle. madem zaman ayırılamıyor, o zaman ept işlerini zaman ayırmak zorunda olduğum bir etkinliğe yedirerek yürütmek şu an için en mantıklı seçenek. ben de öyle yapayım dedim, o projelerden birini (istanbul ulaşım rehberi/karar destek sistemi) bitirme projesi (tezsiz yüksek lisans ya, tez olamıyor) olarak seçtim. başlayıp tamamına erdireceğiz bi' şekil. iett'nin sayfasında benzer bir uygulama var ama bunu bir adım daha geliştireceğiz; bizim uygulamamız canlı trafik verisi üzerinden varış saati tahmini yapacak. veri kaynağı iett ve istanbul büyükşehir belediyesi trafik kontrol merkezi yoğunluk haritası. bunları besleyen birincil kaynaklar (veritabanı ya da web servisi) genel erişime ya da bir programlama arabirimi üzerinden tüketime açık olmadığından programatik şekilde yukarıda adı geçen web kaynakları taranıp ayrı bir veritabanına alınacak. bu veritabanından da bir ulaşım/aktarma ağı ve buna eklemlenmiş bir trafik yoğunluk modeli elde edilecek.

iett hat detaylarının verildiği web sayfaları web standartlarının canına okuyan, çok kötü hazırlanmış sayfalar ve bu nedenle daha önce yine burada bahsettiğim classifier ile okunamıyor. kaba kuvvete, yani regex'e başvurmak farz. trafik datası ise bir flash arabirimi ile sunuluyor, yani herhangi bir web sayfasını okur gibi okumak imkansız. neyse ki bu flash uygulaması bir xml dosyasından besleniyor ve taraması kolay. bu datanın bir eksiği de sadece ana arterlerle ilgili veri sağlaması. ara sokaklar için ayrı bir model kasmak gerekebilir.

bittiğinde güzel olacak sanki...

öldüm bittim eridim

bu yaz süper geçti. okul acayip bezdirdi, iş yoğunluğum tavan yaptı, halen de izine çıkabilmiş değilim. daha süperi can sağlığı.

milyon yıldır salladığım kendi işlerime (ept) sonunda dönebildim. ilk başladığım şey de bir web sayfası tarama paketi. XPath, regex, vs. kullanarak bir web sayfasından seçilen alanların tanım XML'inde belirtilen şekilde bir class'a doldurulmasını sağlıyor.

veritabanı işlemlerinde de linq-to-sql kullanmak işi öğrenmek bakımından çok faydalı oldu. tahmin etmediğim kadar pratik bir yöntem ve veritabanı okuma/yazma işlemlerini çok ama çok kolaylaştırıyor. kesinlikle bir başka ept işinde (mesela byblos) kullanacağım bu şıftırtıyı.

yaptığı işi temiz yapıyor ama biraz yavaş. yavaş olması beni üzen birşey değil; zaten veri toplarken terbiyeyi elden bırakmamak, taranan siteyi sağmamak lazım. neyse, bu iş bitti gibi. şimdilik ek$i datası ile test ediyorum ve her ne kadar bana ilk başta yavaş geldiyse de şu an için hızı tatminkar geldi (karar versene ço-cum...). yine de problemler yok değil. mesela bzen sayfa verisini okuma aşamasında takılıp kalıyor ve 5 dakika sonra timeout verene kadar öylece bekliyor. her türlü timeout değerini denedim, 35 milyon takla attım, bana mısın demedi. durum büyük ihtimalle evdeki çakma megabit bağlantıdan kaynaklanıyor, zira yan odada abim eMule falan kasarken bu durum zirve yapıyor. bir nevi doğa olayı mübarek. işte de denemek lazım yine de, ama şimdi kim uğraşacak veritabanını taşımakla falan...

bu arada esas tarama hedefim altivi. yüksek lisans bitirme projemi bu site ve "sistemi" üzerinde vermek istiyorum. koç mezunu bir ablamıza zamanında site datası vermiştim incelesin diye, bir sormak lazım ne yapmış, ne gibi çıkarımlarda bulunmuş.

nedir?

iş güç derken 3 arabik videoyla geçiştirmişiz blogu. bu sırada mebzul miktarda olay oldu oysa. bankada ilk kısmında dış kaynak kullandığımız (adını verelim, accenture manila) bir projemiz vardı arada egiBlog'da bahsettiğim, daha doğrusu devamlı mızıldandığım. her ne kadar dokümantasyon kısmında bana epey birşey kattı ise de hem süre aşımı hem de dış kaynağın ürettiği kodun kalitesi canımı yeterince sıkmıştı. işte o projenin ürün testi aşaması aralık başında tamamlandı, ben de ygm (yazılım geliştirme müdürlüğü - hell yeah!) içi mahrumiyet bölgesi olan asma kattan eski yerime çıktım, tabi o da ocak'ın 4'ünde 10. kata grupça taşınana dek. kullanıcı kabul testine de haftaya başlanıyor olması lazım; projeyle aramı uzattığım için ancak tahmin edebiliyorum.

şu sıralar da beni sinirden köpür köpür köpürten bir işle uğraşıyorum. bildirim yapmakla yükümlü olduğumuz bir kamu kuruluşunun talep ettiği kimi bilgileri yine onların istediği formatta hazırlayacak bir program. yalnız "format" olarak verdikleri şey evlere şenlik. adres konusunda mesela herşey kodlanmış; il kodu, ilçe kodu, ülke kodu falan, herşey var. süper yani. suudi arabistan'ın, ingiltere'nin, londra'nın da ilçe kodu olduğunu söylersem durum daha iyi anlaşılacaktır ki, söyledim, rahatladım. zaten çok kolay sinirleniyorum şu sıra, iyi değil.

---

geçen ayın başında, soruşturduğumda hiç de sık yapılmadığını öğrendiğim bir etkinliğe katıldım; departmanın yarısı iki otobüse doluşup abant'a eğitime gittik. eğitim deyince, eğitim haftasonu olunca ve katılım da zorunlu olunca iki gün boyunca sıkıntıdan sıkıntı beğeneceğimi düşünüyordum. açıkçası ilk kez herhangi bir konuda yanıldığımdan dolayı memnunum. eğitim de takım çalışması yetkinliklerini geliştirme ve departman için grupları kaynaştırma amaçlıydı zaten. kaynaşmakta üstümüze yoktur tabii :P programda ne vardı? önce her gruba kocamanından bir storyboard kağıdı verildi ve departmanı hangi yemeğe, şarkıya, filme, otomobile, ünlüye, vs. benzettiğimizi, daha sonra sunmak üzere çizmemiz istendi. şunları bulduk:

• şarkı: "bir teselli ver"; iş yoğunluğunun yarattığı her acının tiryakisi olmuş biz mecnunların samimi dileği.


• yemek: patlıcan oturtma; yapımı emek istediğinden ve kendi halinde acı olabilen bir şeyin fena halde lezzetli bir şeye dönüşmesi hikayesini özetlediği için.


• film: "rambo iii"; hassas bir operasyon birimiyz ve bankanın diğer birimlerinin üzerinde iş geliştirdiği platformları hazırlıyoruz. yapılan hataların da etkisi büyük oluyor haliyle. kim attığı okla helikopter düşürebilir ki rambo'dan başka?


• otomobil: doğan görünümlü şahin; yorum yapmaya bile gerek yok, legacy sistemler...


• ünlü: hülya avşar; magazin basını için onunla da olmuyor, onsuz da olmuyor.


• bitki: çam ağacı; her dem yeşil, reçinesi fıstığı falan var, öyle böyle değil.


• hayvan: bukalemun: her duruma uyum sağlar, bir gözü içerideyken diğeri dışarıdadır :)


• eşya: isviçre çakısı; bariz.

işin sunumu bendenize düştü ve -alçakgönüllü davranamayacağım- ortalığı kırıp geçirdim desem yeridir. sunum sahnesinden inerken acayip alkış koptu, diğer sunumların girişlerinde epey bir teşekkür aldım. hala arada kulede karşılaştığım insanlar bana yazılım geliştirme ekibinde harcandığımı söylüyorlar ;P insanların yüzünü güldürmek güzel şey de, şimdilik sevdiğim işi yapıyor olmak daha güzel. değerlendirebileceğim stand-up teklifleri gelene kadar yani, şimdilik (zuhaha).

sonrasında gazete kağıdından belli kurallara uyan (ayaklar arası açıklık falan) bir köprü yaptık ama dereceye giremedik. köprünün adının "veli göçer memorial bridge" olmasının bir etkisi oldu sanırsam. akabinde bir takım egzersizi vardı. ayak basmanın yasak olduğu 3 x 3 metrelik bir alanın en uzak kısmına bırakılan ipuçlarını toplayıp ortaya çıkan mantık bulmacasını çözmek gerekiyordu. ipuçlarını gayet güzel topladık. üç kişi dizleri alanındışında kalacak şekilde elleri üzerinde diz çöktü, onların sırtlarına ayakları gelecek şekilde iki kişi, aynı yöntemle de en uca bir kişiyi ipuçlarına doğru koordineli bir biçimde kaydırdık ve diğer gruplardan önce ipuçlarını elde ettik. buradan sonrası ise tam bir karmaşaydı. ipuçları elden ele gereksiz dolaştı, ekipteki "büyük abiler" kontrolü ellerine almaya çalışırken hem ortak bir noktaya varamadılar hem de kimi zaman fikrini belirten diğer ekip elemanlarına kırıcı davrandılar. bayan elemanlar ortaya üşüşen beyler yüzünden iç halkaya, dolayısıyla çözüme ortak olamadılar. ipuçlrını değerlendirirken kağıt üstünde -abartısız- beş ayrı notasyon gezindi ve muazzam bir zaman kaybı oluştu. hepsi biraraya gelince oyunun ilk yarısındaki avantajımızı kaybettik ve çözümü ik bulduğunu açıkl"ayan ekip olamadık. yine de doğru çözüme ulaştık, ki çözümün içinden çıktığı şartlar gözönünde bulundurulduğunda hiç de fena değilmişiz diyebilirim. eğitim iyiydi, otel ve yemekler vasattı. göl çevresinde dolaşacak zaman bulamamış olmak kötüydü. en güzeli ise departman içinde hem kaynaşma hem de halen devam eden bir pozitif hava yakalanması. düşünsenize, grup müdürlerimizden biri her karşılaştığımızda "başkanım nasılsın?" diyor :P

---

derneğin ilk olağan genel kurulunu yaptık. yönetim kurulunu 1. ('00) ve 2. ('01) mezunlar oluşturdu. başkanımız can. pr/er işleri özge'den, finans samet'ten, it de ertan'dan sorulacak. şahin'in hangi işin boş kalfası olduğunu unuttum. denetmenlerimiz de caner, selçuk ve volkan turan. çok işimiz var. bana daha çok it kısmında iş düşecek tabii. okulu da şöyle bir kolaçan ettim, her zamankinden daha bi' umutlu ayrıldım.

bloga dönüş

döndüm, dönebildim, şeyini şeyettiğimin manila'lılarından kalan zamanımın bir kısımcığını buraya ayırabilecek durumdayım. aman da aman, aman da aman!

dönüş derken, seneler önce erich von däniken'in "yıldızlara dönüş"ünü okumuştum. ufocu zamanlarımdı, büyüdüm geçti. neyse, bahsettiğim kitabın inanılmaz komik, şuna benzer bir girişi vardı: "yıldızlara dönüş! 'dönüş' diyorum, bu yıldızlardan geldik anlamına gelmez mi?" mantık bükmenin, ucuz illüzyonun bu kadarı! blogosferden gelen bir blogonot değilim, ama geri dönmek güzel. birikmişleri bırakmanın vakti gelmişti. ne yapmışız bakalım?

madde 1: the simpsons!
the simpsons movie'ye gittim geçen salı. eğlenceli miydi? kesinlikle. yeri geldiğinde çatlayasıya güldüm mü? evet. ama herşeye rağmen bir sinema filmi havasına giremedim; filmin süresinden (kısalığından) olacak herhalde. spider pig mevzuuna hala yarılmaktayım, şarkı da dilime fena halde yapıştı: "spider pig/spider pig/he does whatever a spider pig does"... hele kuyruk jeneriğine eşlik eden a capella versiyonu harika.

madde 2: egiboy outsourcing öğreniyor
işte dış kaynak kullanılan bir projede çalışıyorum. accenture ile çalışıyoruz ve offshore ekibi manila'da. iki aydır fena halde cebelleşiyoruz ve her ne kadar iki ay böylesi bir konu hakkında fikir edinmek için yeterli olmasa da iki satır laf geveleyebilirim diye düşündüm. dediğim gibi, süreç içinde kendimce çıkarımlarım var outsourcing ile ilgili. öncelikle, iş gücü bakımından 1 + 1 (offshore + onshore) kesinlikle 2 etmiyor; 1,5 ile 1,85 arası (yuvarlak sayı verelim de attığımız anlaşılmasın) bir şey ediyor. kırıma neden olan etmenler ise bence (i) offshore ekibinin benzer bir iş deneyimi olup olmadığı, (ii) onshore ekibinin hazırladığı dokümanların kalitesi ve bunların hazırlanma süresi, (iii) iki katmanlı bir faktör olan dil uyumu; geliştirme dili ve değişken adlarını belirlerken kullanılan dil. her ne kadar 1 + 1 outsourcing matematiğinde 2 etmese de masraf konusunda muazzam bir avantaj yarattığı tartışılmaz. unuttuğum bir noktayı da ekleyip bu bahsi kapatayım; iki ekip arasındaki zaman farkı da çok ama çok önemli. mesela, yaz saatini de ekleyince manila ile aramızda 5-6 saat fark oluyor ve bu nedenle -nacizane fikrimce- çok da uyumlu çalışamıyoruz. amerika-hindistan arası 12 saate yakın, ve böylece bir ekibin bıraktığı yerden öbür ekip alıp götürebiliyor işi, ya da onshore ekibin offshore ekibe doküman yetiştirmesi için çok kasması gerekmiyor. yine de türkiye'den herhangi bir firma yurtdışından dış kaynak kullanmalı mı? ben kendimi pek ikna edemedim; amerika-hindistan arasındaki fiyat uçurumu da yok türkiye-filipinler arasında.

madde 3: moleskine!
bir moleskine aldım. evet, tüketim canavarına tasmasını teslim etmiş bir köpeğim artık ben. yalnız, gerçekten daha fazla yazasım, çizesim, karalayasım var adı geçen nesneyi edindiğimden beri.


inanç zamanından kalma bir kareli defterden başkasıyla çalışamama hastalığım olduğundan moleskine'm de kareli. her türlü taslağı, çizimlerimi, yazılarımı ve saçmalamalarımı ilk önce buraya nakşedeceğim ki ilerleyen zamanlarda daha sağlam saçmalayabileyim :P

madde 4: düğün dernek ve epey kırtasiye
geçen hafta inanç'ın mezunlar derneği ile ilgili gelişmeler oldu. açıkçası, yılan hikayelerini solda sıfır bırakacak bir seyir izleyen dernek işlerinde artık -afedersiniz- "aramızdaki cenabet kim?" diye sormaktan başka birşey gelmiyor elimden. tam yüzdük yüzdük kuyruğunda geldik dediğimiz anda hayvan taze deri ceketini geri aldı bizden! olay da şu; okulun şu anki adı türk eğitim vakfı inanç türkeş özel lisesi (kısaca tevitöl - nazal dekonjestan - türk tıbbı'nın hizmetine sunarız) olduğu için ve okulun şu anki yönetimiyle ili ilişkiler içinde bulunmak istediğimizden derneğin adını "inanç liseliler derneği" yerine içinde tevitöl geçen bi'şey olmasını istedik. istemez olaydık! meğer dernek vesairenin adında "türk" ibaresinin geçmesi için bakanlık izni gerekiyormuş. yasaları bilmemek yasalara bağışıklık salamıyor tabii, ama birkaç kez ve birden fazla avukata inceletilmiş bir metindeki böylesi bir ayrıntının işin uzmanları tarafından atlanmış olması... ne bileyim, içime sinmiyor. hani bülent ecevit'in de içine sinmezdi ya hiçbir şey, aynen öyle. ağustos sonuna kadar bakacağız bi'şeyler, tam detayları ben de bilemiyorum ne yazık ki. umalım ki 30 ağustos'a yetişsin; sezai bey'in huzuruna derneksiz çıkmak da pek içime sinmeyecek zira...

madde 5: girişimciler kulübü girişimi
"yeni ekonomi" hedesi ortaya çıkalıberi herkes bir sonraki parlak fikri bulup, satıp/ürüne çevirip voliyi vurma peşinde. inanç forum'da önce iddialı bir şekilde "gelin şirket kuralım" diye caner'in ortay attığı bir fikrin yine forumda şekillenmiş ve görece daha mütevazı hali diyelim girişimciler kulübü'ne. daha ilk toplantımızı bile yapmış değiliz, çok iddialı da değiliz (daha doğrusu, girişim sermayesi kavramının türkiye'deki görece yokluğu nedeniyle otomatikman kabuğumuza doğru itiliyoruz mütemadiyen). hiçbir şey yapmasak masa başında memleketi kurtarırız, ne gam? tüm inançlı'ları, inanç insanlarını bekliyoruz...

madde 6: yorumsuz blog olmaz, hadi duvaksız gelin bi' derece
özellikle altivi konusunda bloglayıp bir ekşi entry'si ile ufaktan reklam yapınca egiBlog'un ziyaretçisi epey arttı diyebilirim. yine de anlayamadığım bir durum mevcut; gelenler geldiklerini nedense pek belli etmek istemiyorlar sanki. uzun zamandır hiçbir blog girişime yorum yazılmamış. geliyorsanız ses verin, gelecek sefere pencerenin önüne elmalı turtanızı bırakayım. iyi deyin, kötü deyin, ama bir şekilde ses verin.

madde son: bekleyen işler
çok. gerçekten çok. altivi incelemeleri kapsamında bir teklif sayısı takip programı yazmam gerek. belli aralıklarla ilgilenilen ihaleleri ziyaret edip verilen tekliflerin sayısını takip eden ufak bir program olacak bu; atla deve değil yani. bunun üreteceği veri ile eldeki verileri karşılaştırıp altivi kullanıcılarının teklif verme örüntülerini ve en az teklifler ihale kapatmak için bir yöntem olup olmadığını araştıracağım. sonraki işleri de byblos (kütüphane şeysi), ek$iVista online (the ultimate vaporware) ve "muha!" kişisel muhasebe uygulaması sırasıyla önceliklendirdim.

unutmadan, bir detayı daha var altivi uygulamasının. 3 boyutlu bir basit bir grafik çizmekle uğraşıyorum. 3 eksenim olacak: kullanıcı, fiyat ve ihale bitimine kalan süre. her kullanıcı-fiyat-zaman üçlüsünü bir küp olarak göstereceğiz. eksenlere tıklandığında gerçek değerler/frekans toggle'ı yapılacak. kodu c# ile yazıyorum. yol göstermek, kaynak önermek isteyen? 3d çizimi nasıl optimize ederim mesela, görünmeyen kısımları çizmemek yardımcı olabilir, ama bunları nasıl belirlerim? "yol yakınken" falanla bana gelmeyin, çok pis dalarım :P sonuçta bir programcının en sadık dostu ne bilgi ne deneyim ne de acı kahvedir, halis budaklı meşe odunudur.

cidden, yardımlarınız değerinde alınır.

mcinfaaoals - eklemeler

madde madde kasayım olan bitenleri:

• geçen hafta servet'le buluştum, ki onunla görüş(e)meyeli -hiç abartmayayım- üç yıl oluyor. uzakta değilmiş en azından; ben iş kuleleri'ndeyim, o da yapı kredi plaza'daki kpmg istanbul ofisinde. yürüme mesafesi yani. artık daha sık görüşecek olmamız güzel birşey, ama bu konuda servet ne düşünür bilemeyeceğim :P arada, daha doğrusu oraya buraya teftişe çıkmadığı zamanlar da akbank'ta müfettişlik parçalayan erkal da bize katılır herhalde. sözün özü, levent havalisinde ufak bir inanç kliği oluştu, bu civara uğrayanları bekleriz.
• altivi teklif detayları sömürgeni bir uygulama hazırlıyordum makina çökmeden önce, onu tamamladım. acayip kalabalık bir veritabanı oluştu; şimdilik yaklaşık 3800 ihale, 650-700 bin kadar da teklif var incelenecek. ilk izlenimlerim biraz şaşırtıcı, hafiften işkillendirici, sonrasında da fena halde gıcık edici.
  
• şaşırtıcı olan kısmı, eğer altivi sattığı ürünleri "ürün fiyatı" diye duyurduğu fiyattan temin ediyorsa, şu anki teklif sayısı ve teklif bedelleri göz önünde bulundurulduğunda yaklaşık 2 milyon ytl kadar zararda görünüyor. tabii ki, bu gayet naif bir varsayım; yani piyasa fiyatlarından biraz daha düşük fiyatlarla satınalım yapıyor olmaları beklenir. altivi'den mi yoksa başka bir yerdenmi okudum çok iyi hatırlamıyorum, ama stok tutmadıkları şeklinde bir bilgi/duyum var ki, toptan alım yapmadan nasıl indirim alınabilindiğini çözemedim. indirim demişken, perakende fiyatı üzerinden yaklaşık %25 indirim almış olmaları gerekiyor, o da başa baş noktasına gelinmesi için. bu durumda ya stok tutuyorlar, ya da distribütörlerden acayip kelepir mal kapatıyorlar.
  
• işkillendirici olan, tekliflerin önemli bir kısmının son dakika içinde yapılmış olması, hatta birçok durumda tekliflerin neredeyse kazanan rakamı ya merkez alacak şekilde, ya da ucu ucuna içerecek aralıklar içinde verilmesi. eğer verdiğiniz teklif grubundan daha sonra teklif verilmeyeceğinden eminseniz o zamana kadar verilen teklif sayısından 1 fazla teklifi en yüksek fiyattan aşağı doğru verirseniz kazanmanız garanti, ama bu da çoğu zaman karlı olmuyor. esas işkillendirici olan ise tekliflerin veriliş şekli değil, bunların altivi ekibi tarafından verilen dummy, "keriz silkeleme" amaçlı teklifler olma ihtimali. bu bakımdan biraz şeffaflığa ihtiyacı var altivi'nin.
• gıcık edici kısım kendini sitenin "yasal uyarı" kısmında gösteriyor. deniyor ki:

  AL SATIŞ bu internet sitesinin genel görünüm ve dizaynı ile internet sitesindeki tüm bilgi, resim, AL TİVİ markası ve diğer markalar, www.altivi.com ve www.altivi.com.tr alan adları, logo, ikon, demonstratif, yazılı, elektronik, grafik veya makinede okunabilir şekilde sunulan teknik veriler, bilgisayar yazılımları, uygulanan satış sistemi, iş metodu ve iş modeli de dahil tüm materyallerin (“Materyaller”) ve bunlara ilişkin fikri ve sınai mülkiyet haklarının sahibi veya lisans sahibidir ve yasal koruma altındadır.

  bold italic kısım beni değil gıcık, resmen ifrit etti. takası icat eden adam patentini almayarak aptallık mı etmiş? bu işi ilk sen mi yapmışsın, mucidi sen misin? hepsini geçtim, bir satış yöntemi herhangi bir şekilde fikri koruma altına alınabilir mi? bana göre tüm bu soruların cevabı hayır. öncelikle bu iş altivi'cilerin gri hücrelerinin mahsulü değil, kendilerinden önce açılmış örnekler var (mesela http://www.limbo.com/), satış yöntemi de çok taze değil, o halde pazarı kapatmak için böyle bir cinliğe başvuruyoruz. ayıp değildir de nedir yani şimdi bu? incelemelerimiz sürecek; e, soruşturmacı gazeteciliğin tadını aldık bir kere, durmak olur mu :P
• her bir procem beklemede, ama artık suçu zamansızlığa değil de maymun iştahlılığa bağlıyorum artık. bir onunla uğraşayım, bir de şuna bakayım derken hiçbiriyle hakkıyla ilgilenemiyorum. işleri bir öncelik sırasına koyup teker teker ele almak en doğrusu...
• gödel, escher, bach: an eternal golden braid... hastası olduğum, her elime alıp sayfalarını karıştırdığımda mutlaka bir şekilde beni şaşırtan, afallatan, aynı anda hem daha zeki ve daha aptal, eksik hissettiren bir kitap. koç'tayken orijinalinden, ucundan kenarından nasiplenebilmiştim. sonra kabalcı'dan türkçe çevirisinin çıktığını öğrendim ve bir tane edindim. çevirisi fena sayılmaz ve kesinlikle öneririm, özellikle temel bilimciler ve mühendislere. tabii, imkanınız varsa orijinalinden, doğrudan douglas hofstadter'in elinden çıkma metni takip etmeniz daha uygun, daha güzel olur.
• işte ise yepyeni bir macera: "iş bankası outsourcing öğreniyor". accenture ile çalışıyor, onların manila'daki ekibine işleri usulünce yapabilsinler diye deli gibi doküman hazırlıyoruz. hatta geçen gün 2 saat telekonferansla elemanlara belli tip bir servisin nasıl yazılacağıyla ilgili sunum yaptım. hiç yapmadığım şey... neyse ki iyi gitti. işin garibi, yazılım departmanında kod yazmayı özledim, hazır -ve ne yazık ki köhnemiş- codebase üzerinde at koşturmak yerine yeni bir şeyler yapmayı özledim.

biriktirip biriktirip patlıyoruz işte böyle efendim.

the dramatic look

her izlediğimde ayrı yarılıyorum :P

yarın turhan hoca (alnıtemiz) ve ufaklardan kadir ile bi' proce üzerine kasacaz sabahtan. bakalım... ne olacağını ben de çok merak ediyorum.

altivi analiz programının da veri toplama (screen scraping) kısmını yazdım, analiz kısmı kaldı. cevabını merak ettiğim temel sorular bir ihaleyi kazanmaya yetecek en az teklif sayısı ve bu tekilflerin dağılımı (yüzdelik dilim benzeri). tüm bunlar ürün kategorisi, ürün ve fiyat aralıkları göz önünde bulundurularak irdelenmeli tabii.

altivi

altivi internet'te denk gelebileceğiniz sayısız alışveriş sitesinden biri, ama ürünleri satış mantığıyla diğerlerinden biraz farklı. sattığı her üründen sadece 1 adet satıyor, ki bu türlü çalışan bir sürü açık artırma sitesi var. ancak, sattığı ürüne sınırlı sayıda teklif alıyor ve teklif vermek ücretli, ayrıca teklif süresi de kısıtlı. satış sürecine formal takılalım diye "ihale" demişler, ki hafif bir ihaleye girme tadı da veriyor site üyelerine. ihaleyi ise, en yüksek benzersiz teklifi veren kazanıyor. "benzersiz teklif?" dediğinizi duyar gibiyim, açayım. bir ürüne şu şekilde teklifler gelsin:

1. 100 ytl
2. 101 ytl
3. 99 ytl
4. 98 ytl
5. 101 ytl
6. 100 ytl

tüm tekliflerin, bu örnek için ayrı kişilerden geldiğini varsayalım (ki birden fazla teklif yapmak serbest). ihale sonucunda 99 ytl'lk 3. teklifi vermiş olan kişi ihaleyi kazanıyor, çünkü onun üstünde kalan 100 ytl ve 101 ytl'lik ikişer teklif var.

reklam olsun diye yazmıyorum bunları, sitenin sahiplerini de tanımam. dikkat çekmek istediğim şey, çok değişik ve -hakkında ekşi'de yazılan yorumları okuduktan sonra- belki ileride kimi yasal problemlerle başı ağrıyabilecek bir iş modeliyle karşı karşıya olduğumuz. yurtdışında benzer örnekleri yoksa, piyasada iş modeli geliştirebilecek insanların bulunduğunu görmek sevindirici birşey.

yine de, işe patron ya da maliyeci değil de alıcı gözüyle bakarsak, bu tür bir sistemden maksimum faydayı elde etmek için bir sistem geliştirmeye çalışmak en mantıklısı olacaktır. bitmiş ihalelere ait teklifler sitede görüntülenebiliyor, ve web scraping ile bu bilgiler bir veritabanına aktarılabilir ve buradan birtakım sorulara yanıt aranabilir. aklıma gelenler şunlar:

• bir ihaleyi kazanabilmek için en az kaç teklif, hangi örüntüyle verilmeli?
• üyelerin tipik bir teklif verme davranışı var mı, birden fazla ise bunlar nasıl kategorize edilebilir?
• brute force (bu durumda bol para) ile ihalelere girenlere karşı diğer üyelerin bir şansı var mı?
• tüm bu olayın game-theoretic bir ilginçliği var mı, incelemeye değer mi?
  

bunlar üzerinde kafa patlatılabilir, çünkü mantıklı bir şekilde ihalelere girip kazanırsanız, almak istediğiniz şeyleri çok ama çok ucuza getirebiliyorsunuz. 10 bin liraya otomobil mesela!

pseudocode iyidir...

az önce mine'nin python şeysi için pseudocode yazip gonderdim. pseudocode iyidir, çünkü her zaman çalışır... kağıt üstünde tabii :) umarım işine yarar...

onun haricinde, bir ara burada anladığım ex libris olayını tam teşekküllü bir kütüphane otomasyon olayına çeviriyorum hiç işim gücüm yokmuş gibi. db'sini hazırladım, 10 civarı tablosu var, işlemlerin çalışma mantığını da hazırladıktan sonra iki satır koda bakar olay.

iki gün mesaiye kaldım. değil pestilim, nano düzeyde filmim çıktı. taksiyle kule-ev(kartal) arası 1. köprüden 40, 2. köprüden 47 lira tutuyormuş bu arada, test ettim onayladım.

ek$iVista grafik şeysi...

grafiği çizdirmek için wikipedia'da bir gıdım pseudocode buldum, yalnız benim çizdirmek istediğim grafik için ne kadar ölçeklenebilir bilemiyorum. olayımız ise şöyle; grafiğimiz tipik bir yönlü çizge (directed graph) ve çizgemiz köşe ve kenarlardan (vertices and edges) oluşmakta. force-directed yaklaşımda köşelerimizi eş yüklü parçacıklar, kenarlarımızı da birim uzunlukta türdeş (öss günlerim geldi aklıma birden-türdeş!) yaylar olarak kabul ediyoruz ve oluşturduğumuz çizgenin köşelerini rastgele düzleme dağıtıp sistemin hooke ve coulomb kanunlarına göre dengelenmesini bekliyoruz. ortaya gayet estetik, takip etmesi kolay çizgeler çıkıyor, yalnız yukarıda bahsetiğim ölçeklenme problemi had safhada; kulanılan algoritmanın hesaplamasal karmaşıklığı (böyle mi çevirmeliyiz computational complexity'yi?) n^3 seviyesinde! oha ki ne oha!

ya balık gözü benzeri, yalnızca odaktaki başlığın 2 link ilerisini göstereceğim, ya da başkaca yöntemler bulacağız; artık genetic mi kasarız, apayrı birşey mi kastırırız bilmem.

of ya, of!

strictly confidential

yaptığım şeyleri anlatmayı çok isterdim, ama hepsi yeni (ve göğüs kabartıcı kısmı, başka yerde olmayan) bir ürünün parçası olduğundan dolayı yapamıyorum bunu. onun haricinde bankanın tüm hesaplar üzerinde çalışan yeni karlılık programlarını yazdım. hesaplamalar basit, ama aynı işlem milyonlarca türk lirası ve yabancı para cinsinden hesap üzerinde çalışacağı için performansı yerlerde sürünmeyen, temiz kod yazmak gerekiyor. süreç içinde bir taraflarım çıkmadı dersem yalan olur, zira bir sürü kurum içi standart falan fiştan mevcut. eski tarihlerde yazılmış milyon tane program var, ve bunların önemli bölümünde bu standartlara uygunluk göremeyince "bize de mi kopenhag kriterleri lan?" demeden edemiyor insan :P

vaporware'lerim listesinin güncellenmiş halini de ekleyeyim, bu post'umuz da burada bitiversin:

• versaTile simulasyon (simülasyon yazanı budaklı meşe odunuyla döverim, şiddetten yanayım, arz ederim)/erp şeysi
• bununla ilgili hiçbir şey yapmadım, drawing board aşamasını geçemedi hala.
  
• quant anket/test/e-learning aracı
• sayfaları oluşturmakta kullanılacak markup dili üzerinde çalışıyorum, ama ürünün hedef kitlesini bilgisayar ve programlamayla ilişkileri kısıtlı öretim elemanları olduğundan dolayı iyi bir şablon takımı da hazırlamak şart. sık kullanılan/kullanılabilir soru tiplerini tespit etmeli.
• esas işe yarayabilecek şey, komşusundan haberdar seçenek kutucukları tasarlamak olacak sanki. birçok ankette yanıtlar bir matristen seçiliyor, ve böyle soru tiplerinde bu tip seçenek kutuları işleri kolaylaştırabilir.
• bildiğimiz lineer, başladığı gibi biten testlerden ayrı olarak verilen yanıta göre dallanıp budaklanan, ya da toefl'daki gibi soru bankasından yeni soru seçen yapıları da eklemeyi düşünüyorum.
• test yayın ortamı internet olacağı gibi, test tasarım ortamı da web tabanlı olacak. sürükle-bırak ve snap-to-grid olaylarını öğrenmem lazım, bir de on-the-fly syntax highlighting yapıcam, tadından yenmeyecek.
  
• ek$iVista online
• grafik çizimi ile ilgili bir kitap buldum, ama yemek arasında ya da hafta sonunda taksim'e gitmeye fena halde üşendiğimden pandora'da, literatür'de ya da robinson crusoe 389'da var mıdır diye soramadım. krugle ya da koders'dan başka dilde hazır kod bulup apartmaktansa pseudocode'dan hareketle kendim yazarım daha iyi.
• ek olarak bir başlık sınıflandırma sistemi planlıyorum, ama bunun için kategoriler belirlemem ve elimdeki sözlük verisinden bir corpus oluşturmam lazım. corpus'u oluşturduktan sonra deli pösteki sayar gibi kategoriler içinde her kelime puanlanacak, bu kelimeleri içeren entry'lerin başlık içindeki sırasına, kelimenin link içinde geçip geçmediğine, vs., göre her kategori için başlıkların puanları oluşacak. "başlıkları alt alta okumak" başlığını analiz etmek istemem doğrusu, şizofrene bağlar makina |--<8^~
• erdös number olayı gibi x yazarının y yazarı numarasını bulacağım eğlence olsun diye. en kolay kısmı da bu zaten, ve bu sayının hangi yazar çifti seçilirse seçilsin çok yüksek çıkacağını tahmin etmiyorum.
  
• geçen thinkGeek'de şöyle bir dalgametre gördüm. alınası bir şey, ama bunu alıp hemen orayı burayı özgürleştirmekten (öhö) daha eğlenceli bir (sayıyla 1) şey var; parçaları toplayıp, başka bir işim yokmuş gibi aletin bir benzerini yapmak!
• selanik pasajı ya da yazıcıoğlu'na yollanmadan önce öğrenmem gereken şeyler var; usb arabiriminden veri nasıl gönderilir, hareket elemanları olan servolara nasıl komut gönderilir, falan da filan.
• bunu bir de sensörlü, yolunu belirli bir dereceye kadar kendi bulabilen ama gerektiğinde uzaktan kumanda edilebilen bir aletin üzerine monte edersem tam süper olacak. bitirip deneme aşamasına gelirsem ilk denemelerimden birini kulede yapacağım. muhasebeye giden en kısa yol olsa gerek bu :P

odama, yurt odamın kapısına astığım gibi bir "karalama posteri" asmam lazım biraz olsun ilerleyebilmem için; blog bu işin hakkını veremiyor pek... ek$iAPI için kasarken gayet faydası olmuştu, şimdi de olmaması hiçin hiçbir neden yok.

egiboy planlama teşkilatı günlük hayat gözden geçirme raporu #3

süper planlarım var, daha çok software üzerine.

bir iki uygulama yazmayı planlıyorum.

anket ve test tasarımı yapabilecek, bunları bir DB'de saklayabilecek ve gelen yanıtları değerlendirebilecek bir uygulama. tercihan bir web uygulaması olacak biri. diğerleri daha herhangi bir zemin üzerinde yoğuşamayacak kadar sıcak, yeterince soğuduğunda haberiniz olur.

bi' de, mrs watson gelecek ya, heyecan var biraz :P

hexaStrat indirme linki

http://rapidshare.de/files/26255188/HexaStrat.rar.html

13 kB'çık bi'şey. tabi, eğer sizde kurulu değilse indirip kurmak zorunda kalacağınız .net framework 2.0 redist package'ı saymazsak :P

bu arada, daha önce bahsettiğim online oynanabilirlik olayını şimdilik rafa kaldırıyorum. neden? üşendim desem?

kurallar ve akış ise şöyle:

1. kimin başlayacağını belirleyen zar atışlarına her zaman kırmızı oyuncu başlar.
2. oyuna başlandıktan sonra oyuncular 6 attıklarında isterlerse zarı tekrar atabilirler.
3. 3 çeşit hamle vardır: takas, taş yeme ve taş yürütme.
4. taş yürütme hamlelerinde daha önce geçilen bir kareden tekrar geçilebilir. taşlarımızın seyahat özgürlüğü aihs ve evrensel insan hakları sözleşmesi ile garanti altına alınmıştır. dolu karelerin üzerinden atlanamaz, sadece boş karelere hareket edilebilir. geçerli hamleler zaten sizin için işaretlenmektedir, bu da bir nevi tur operatörlüğü servisi, bir başka bakımdan da sovyet "kapalı şehir" uygulamasının oyun dünyasında tezahürüdür.
   
5. iki çeşit takas ve taş yeme hamlesi vardır, zarın değerine göre ve zarın işaret ettiği yöne göre. zarın değerine göre takasta seçilen taş, zarda gelen sayıyı taşıyan herhangi bir taşla değiştirilebilir, taş yemede ise seçili taşın yiyeceği taş hem seçilen taşa komşu olmalı, hem de zarda gelen sayıyı taşımalıdır. zarın işaret ettiği yön ise şöyle tayin edilebilir; zarda gelen sayıyı 2 ile çarpın ve saat kadranı üzerindeki yönünü bulun, örneğin 3 attığınızda zarın işaret ettiği yön saat 6 yönü, yani seçili taşın hemen altındaki taştır.
6. oyuncu zar atıp hamlesini ilgili butonlara basarak seçer, ve sadece seçilen hamle geçersiz ise oyuncunun yeni bir hamle seçmesine izin verilir. hamleler geri alınamaz.
7. hamle butonuna basılıp belirlendikten sonra oyuncu kendi taşlarından birine tıklayarak hamleyi yapacak taşı belirler. ilk tıklamada taş seçimi kesinleştirilmez, ama seçili taş, seçildiğini belirtir şekilde sarı renkle işaretlenir. bu aşamada oyuncu kendine ait başka bir taşı tıklarsa o taşın rengi sarı olur, önceki tıkladığı ise eski rengine döner.
8. sarı renkli bir taş tıklandığında hamleyi yapacak taş kesinleiştirilir ve rengi yeşile dönüşür. bu aşamada taşın yapabileceği geçerli hamlelerde hedef olacak taşlar sarı ile işaretlenir. ayrıca, eğer zarın işaret ettiği yöne göre bir hamlenin hedefiyse hedef taşın üstünde bir "crosshair", zarın değerine göre bir hamlenin hedefiyse çember içinde 1 sayısı taşın yüzeyinde belirir. örnekleri yandaki resimde görülebilir.
9. rakibinin hiçbir taşını tahtada bırakmayan oyuncu kazanır.

oyunla ilgili önceki post'lar için: I, II

hexaStrat revisited

öncelikle buraya bakın derim ben.


bugün sabah gibi oyunun ana kısmını bitirdim. tıkır tıkır çalışıyor, hatta hamle bile öneriyor oyunculara, o derece yani :P




işin kozmetik kısmı kaldı, bir de internet ya da ağ üzerinden oynanabilir hale getireceğim. basit ve umarım insanların zevk alabileceği bir oyun oldu. her biri tamam olunca linkini de veririm artık...

comp 491: report | references

References

1. http://en.wikipedia.org/ (“What is Ekşi Sözlük?” section)
2. http://msdn.microsoft.com/
3. http://www.codeproject.com/
4. http://jung.sourceforge.net/ (The basic ideas for the circular layout)
5. http://netron.sourceforge.net/ (The graph visualization package and documentation)
6. http://graphviz.org/ (Information about various graph libraries)
7. C# How to Program, Deitel & Deitel, Prentice Hall, 2001

finito?!?

comp 491: report | conclusion

Conclusion

This project, while it only consisted of ek$iAPI, had started as an exercise in C#, not thinking that a senior design project could be based on it. The source of inspiration for this graph visualization application was the Skitter(*) project which also featured a circular graph, but laid out in a completely different fashion.

After making the decision of doing this project, a tremendous amount of effort was expended to complete it. However, even more could have been expended for a total fulfillment. Quoting from the Preliminary Report:

“Scope: A detailed inspection of Ekşi Sözlük data in the form of a digraph as a way of representation, with some simple algorithms employed for coming up with the digraph. Extensions, such as marking the titles one specific suser has written, finding cycles of association or creating timelines (or a histogram) of activity for a specific title can also be implemented.”

“The latter and final step is to design and implement the graphing tool which will work on the extracted data. This tool will make use of some simple algorithms or checks. Some are:

• Checking the number of entries under a destination title before assigning a connection between two nodes depicting titles. This will be necessary, as links sometimes are used for other purposes by susers, such as emphasizing a part of the entry. Also, some links point to non-existent titles which should be eliminated.
• Possibly, a node distribution algorithm, so that no node of the graph overlaps with another to allow clarity of presentation.”
  

The prime objective of the project can be said to be accomplished, as a digraph is generated by ek$iVista. There is a very, very simple algorithm to come up with the digraph; no need was seen for checking the number of entries under a destination title as that quantity carries no importance. References pointing to single entries and clever references were left out, because the connections sought have to be between titles and clever references are generally used to make remarks about a fact and carry no little referential value. The envisaged extensions that were left out in the first version of ek$iVista are implemented in the second, such as the activity histogram or a list of common titles of two arbitrary susers.

Of course, there is plenty of room for improvement. Edges or vertices could be colored according to a measure, such as the number of links from the edge, or susers in the ”yazarlar” tab could be assigned different icons according to their generations

As I stated above, this project started as a small exercise in C# language and expanded into a much bulkier one, helping me master very crucial constructs; accessing databases, acquiring data from the Internet, working with basic graphics, using proprietary packages and many other skills.

Hoping that somebody comes up with a programming language exercise that also improves one’s time management skills…

K. Egemen Şentin
27.01.2006, updated 11.02.2006

(*)Website: http://www.caida.org/analysis/topology/as_core_network/

comp 491: report | ek$iVista

ek$iVista

The Problem: Designing a program that generates a digraph from the edge data generated by ek$iEdgeDump.

Design: This part of the project was the most troublesome part, involving a cascade of decisions. As the project supervisor, Prof. Attila Gürsoy advised making use of graph layout libraries, such as JUNG(*) (Java Universal Network/Graph Framework), yWorks(**) or GraphViz(***). During the research phase, however, it was observed that neither of these options was worth the effort; JUNG could not be used within C#, yWorks was a commercial package with costs beyond my budget for the foreseeable future, GraphViz seemed too hard to implement. Later on, I found a Windows DLL port of GraphViz(****) and modified ek$iVista to generate a text file in DOT format (file format accepted by GraphViz). However, the lexer inside GraphViz could not parse the text file generated by ek$iVista with no apparent reason, so the use of the GraphViz was out of question. It was becoming obvious that the layout algorithm and generation of the diagram had to be handmade.

From a very large array of layout algorithms, like the Kamada Kawai algorithm, a random vertex-placement algorithm and many tree layout algorithms, the circle layout was chosen, because in this layout, the vertices were pushed near the borders of the diagram and the center part was left vacant for the edges to be placed. Also, the coordinates of vertices and edges could be calculated by simple trigonometry. First of all, a minimum distance between two vertices is defined; let us name it md. If there are v vertices laid out evenly on the perimeter of a circle, the perimeter is expected to be roughly (md x v) units. The radius of the circle, hence, is (md x v)/2π. The position of the nth vertex on the diagram, given the center of the diagram as the Cartesian pair (cx, cy) is the Cartesian pair (cx + cos(360n/v)((md x v)/2π), cy + sin(360n/v)((md x v)/2π)). As we know the coordinates of the vertices and have a list of edges, drawing the directed edges should be trivial.

Everything is expected to fit in without any problems, but expectations are not always met. For enabling interactive vertices that respond to clicks, a control named VistaVertex was created which contained four buttons envisaged to fire some events and methods. However, as the number of vertices rose, the application became more than cumbersome. Also, an unadvertised “feature” of Windows surfaced; one cannot create more than 10,000 controls per application, because Windows cannot generate “handles” for them. Because of this limitation, the use of controls was impossible; the diagram had to be painted on the form and it could not be interactive for the time being. During this phase, I had mounting difficulties when the form had to be refreshed, because whole diagram had to be painted from scratch and I could not figure out a method to avoid this. Finally, I decided to generate a viewable image by using the graphics libraries provided in C#, and discovered another hidden limitation; drawing images larger than 32,678 x 32,768 was impossible. Such a limitation was also imposed upon the size of forms; although the property that keeps the height and width of the form is of type Int32 (2³² ≈ 4 x 10⁹), the maximum value it accepted was 215. With the current number of vertices, however, this poses no big problem.

The program first reads the source titles into a Hashtable and gets the total number of vertices. After this, a SortedList (a Hashtable sorted according to the keys of the items) object is populated by Point objects that store the calculated coordinates of the vertices with the title names assigned as their keys. Then, EksiEdgeData table is read from beginning to end; if the source title corresponds to a key in the hashtable, the directed edge is drawn. After all the edges are drawn, the vertices are drawn onto the image, and finally, the image is saved at a fixed location, the root of the C:\ drive.

-assume that here placed is a friggin' large image which resembles the lunar surface or a colour-inverted solar eclipse-

The graph drawn by ek$iVista, although substantially rich in data, is not very adept at displaying the connections between Ekşi Sözlük titles as much of the meaning is lost in the clutter. As it was stated before, the “final” graph produced contained the details of only a small portion of Ekşi Sözlük data and finally, the graph, although envisaged to be interactive at first, was far from interactivity. To rectify these shortcomings, a new version for ek$iVista was written. A new problem statement would do this new application justice, and it is given below:

The Problem: Providing means of visualizing and analyzing Ekşi Sözlük data gathered by ek$iDump – especially the links between titles and the users contributing to titles. Also, correcting the flaws of the first version; trying to draw the whole graph which makes it unintelligible, having to rely on a separate table (EksiEdgeData) generated beforehand to come up with the graph while the data for it could be generated on-the-fly, and providing no outlets for interactivity.

Design and Implementation: The first design decisions were about what to include in this application and what to leave out. To see what has been done clearly, let us use a weekly update mail as our checklist:

“I spotted a graph visualization package named Netron (http://netron.sourceforge.net/) and will be using this package for the title connections graph.”

The graph visualization package that has been used, as it is stated above, is an open-source package named Netron, an initiative started by François Vanderseypen to provide a functional library of tools written in C# for producing diagrams in .NET platform. Netron contains many object types necessary to draw a connectivity graph and also some layout algorithms, such as the tree layout, random layout and the spring embedder. As the library is open source, it is freely extensible. Another interesting feature of this library is its support for drawing cellular automata outputs. The title connectivity graph generated by ek$iVista makes use of this library and the layout algorithm chosen is the spring embedder algorithm.

• “The queries that I am going to use in ek$iVista are:
• The one that will be used to draw the connectivity graph (with the option of displaying titles 1, 2, 3, 4 and 5 clicks ahead)
• Simple queries that will list the users who contributed to the title and the entries under the title (with the option of opening it from the database with or directly from Ekşi Sözlük)
• Queries that will help to draw timelines for activity, for titles and users
• A query for finding the "intersection set" of the titles written to by two distinct users”

All the queries mentioned above are included with one addition and one exception; the option of opening the entries under a title from the database was omitted as Ekşi Sözlük contained the most up-to-date information on any title imaginable, and as listing more than 700,000 titles in a combo box used to select the title to work on is a fairly daunting task, a query for listing the 10 titles most relevant to the given input was added. These queries were implemented as stored procedures as the data traffic is minimized between the application and the RDBMS and time is used more efficiently as stored procedures precompiled and prepared; they do not have to be compiled over and over like other SQL statements. The number of stored procedures used is five, and they are:

top10matching: Returns the first 10 matches to the title value input.

CREATE PROCEDURE top10matching @whattitle nvarchar(50) AS SELECT TOP 10 title FROM Titles WHERE title LIKE @whattitle

entryProc: Returns the full list of entries entered under a title.
CREATE PROCEDURE entryProc @whattitle nvarchar(50) AS SELECT * FROM Entries WHERE title = @whattitle
suserIntitle: Returns the full list of susers (without repetition) under a title.

PROCEDURE suserInTitle @whattitle nvarchar(50) AS SELECT dbo.Susers.suser, dbo.Susers.suserID FROM dbo.Susers INNER JOIN dbo.Entries ON dbo.Susers.suserID = dbo.Entries.suserID WHERE (dbo.Entries.title = @whattitle) GROUP BY dbo.Susers.suser, dbo.Susers.suserID

entriesOfSuser: Returns the full list of entries contributed by a suser.

ALTER PROCEDURE entriesOfSuser @whatsuser int AS SELECT * FROM Entries WHERE suserID = @whatsuser
togetherProc: Returns the titles (without repetition) written to by both of the two given susers.

PROCEDURE togetherProc @id1 int, @id2 int AS SELECT title FROM dbo.Entries WHERE (suserID = @id1) GROUP BY title HAVING (title IN (SELECT title FROM dbo.Entries WHERE suserID = @id2))


Although the queries used are fairly simple (the last one is a simple nested query) any timewise gain obtainable had to be obtained, because the system the database runs on (an AMD Athlon 2000+ with 512 MB main memory) is not very powerful as to meet Microsoft SQL Server’s needs.

Other design decisions will be explained in detail in the Walkthrough section, where a normal run of ek$iVista is exhibited.

Walkthrough:
A splash screen like this welcomes the users of ek$iVista.

Fig. 6: Splash screen of ek$iVista

If not desired, it can be eliminated by passing /nosplash argument before running the application. The splash screen was seen as necessary because the user has to be sure that the program is functioning normally as the application strives to scan all (exact number is 781, 367) of the titles in the database and add them to a Hashtable which will be used to check whether the destination titles exist or not. After the scanning of titles is complete, the main form of the application is displayed:

Fig. 7: ek$iVista - overview

As one can see, the interface is fairly simple with TabView components used as sub-forms. An MDI (Multiple Document Interface) form could have been used instead, but MDI forms are not very easy for the end user to deal with and can get scattered around, providing a messy outlook. The tabs contain controls that help display the outcomes produced by the program; “başlık bağlantı grafiği” (title connectivity graph) displays the connectivity graph of a title by making use of the Netron graph control, “browser” displays the contents of titles in Ekşi Sözlük with the help of an Internet Explorer control, “etkinlik grafiği” (activity graph) displays the activity recorded under a title or of a suser in the form of a 3D bar chart with the aid of a Microsoft Chart control, and “yazarlar” (writers) and “ortak başlıklar” (common titles) display the writers (susers) under a title and the common titles of two susers, respectively. These two tabs make use of the ListView control.

At the main entry point, we begin by entering some text in the text box under the label “aradığınız başlık” (the title you are looking for). As one types further, the list below the text box is updated by using the top10matching query to list the 10 titles that are the most relevant to the text entered. This feature helps users to narrow down their searches and find titles when they are not sure of the title they want to inspect. An example is given below.

Fig. 8: Title search feature

We advance by selecting a title from the list, select a value for the hop distance (between 1 and 5, inclusive) from the number selector and click “bağlantı grafiğini çiz” (draw connectivity diagram) to see the connectivity graph with the selected title as the center and the titles at the clicking distance selected from the number selector. If one clicks the button without selecting a title from the list, an error message is displayed.

Fig. 9: Error message - "A title should be chosen from the list."

This connectivity graph is drawn by a BFS (breadth-first search) – like algorithm which takes a starting node (title) and scans through the entries under a title, adding the links inside the entries to a list and drawing the connections between them. If the final hop value is not reached, the titles inside the list formed are scanned and the method for drawing the graph is called for every value in the list.

The graph drawn when the selected title is “inanç lisesi” (the high school that I was graduated from – now known as TEV İnanç Türkeş Özel Lisesi(*****)) and the hop distance as 1 is shown below, with the context menu shown when a title is clicked.

Fig. 10: Title connectivity graph with its context menu

The context menu options are:

• “benzer başlık bul” (find similar titles) posts the title name to the text box labeled “aradığınız başlık”,
• “yazarları göster” (show writers) displays the list of susers who contributed to the title in the “yazarlar” tab,
• “etkinlik grafiği” (activity graph) shows the activity graph of the title in the “etkinlik grafiği” tab,
• “ek$i’de aç” (open in ek$i), as its name suggests, opens the title in Ekşi Sözlük, displayed in the “browser” tab.
  

Let us see who has written under the title “mit” by clicking the appropriate menu item. The result, produced by the susersInTitle query, is shown in Fig. 11:

Fig. 11: The list of users who have written under the title "mit"

The activity graph of the title “mit” is obtained by clicking “etkinlik grafiği” in the context menu, which is a bar chart displaying the monthly entry counts of a title or a suser. Three types of activity graphs exist; a general view which displays months, years and number of entries on the axes, the month-based view which shows the counts of entries entered in the 12 months of the year and the year-based view which shows the entry counts corresponding to the years starting from 1999, the year Ekşi Sözlük was established. All three graphs are shown below, in Figs. 12:

Figs. 12: General, monthly and yearly activity graphs for the title "mit"

Activity graphs are obtained by calling queries that return entry data. In this entry data, the date the entry was entered is stored as a string value, since, in Ekşi Sözlük, both the date of entry and – if the title is edited later on – the date of the latest edit is stored. As it was not desirable by the designer to work on tables that contain null values (the edit date for entries that are not edited), this scheme of storing date values was adopted; strings can be programmatically parsed down to integer values.

A two-dimensional integer array for storing entry frequencies is created and for every entry data acquired, the date string is obtained, the month and year value is picked and the frequency value corresponding to the month and year value is incremented by one. After all the entry values are consumed, the array is fed to the graph control as data, and thus the activity graph is drawn.

Going back to Fig. 11, we can experience more of the functionality of ek$iVista. When we right-click any portion of the susers list, a context menu appears as shown in Fig. 13. This context menu provides two choices for the user; “ortak başlıkları listele” (list common titles), when two suser names are selected, lists their common titles in “ortak başlıklar” (common titles) tab, and “etkinlik grafiği” (activity graph) which displays the activity graph pertaining to the selected suser. If the selection criteria (selecting 2 susers for “ortak başlıkları listele” or selecting 1 suser for “etkinlik grafiği”) are not met, error messages are displayed. Let us see what happens when we choose two arbitrary susers from the list and request to see their common titles. The common titles list for the susers “yasland” and “zeytin” are shown in the figure below:

Fig. 13: Common titles list for the users "yasland" and "zeytin"

The items in this tab, “ortak başlıklar”, have the same functionality as any title node in the connectivity graph and have the same context menu. Thus, the details can be inferred from the lines above which mention this context list.

(*): Detailed information about JUNG can be obtained from http://jung.sourceforge.net/.
(**): Website: http://www.yworks.com/
(***): Website: http://graphviz.org/
(****): Website: http://home.so-net.net.tw/oodtsen/wingraphviz/index.htm
(****): Website: http://home.so-net.net.tw/oodtsen/wingraphviz/index.htm
(*****): Detailed information can be obtained from http://www.tev.org.tr/ or http://tevitol.k12.tr/.

comp 491: report | ek$iEdgeDump

ek$iEdgeDump

The Problem: Extracting links (connections) from the existing “heap” of entries.

Design: For ek$iVista to be able to function, to be able to produce a digraph, it needs a list of directed edges, and ek$iEdgeDump was produced for this purpose. For the sake of simplicity, like ek$iDump, it is also designed as a console application. During the development, two versions of ek$iEdgeDump were produced. The first version gets the full list of titles in the database (a table named Titles exists in the database) and scans them one by one. In this scan, the entries under the title being scanned are inspected and any link that points to a title (those that point to single entries are omitted) is parsed out of the entry text. Then, another database query checks whether the title pointed by the link exists in the title list. If it exists, the pair consisting of the IDs of the source title and the destination title (the records in the Titles table have a title ID and title name) are written to a table named EdgeData, only to be used by ek$iVista in drawing the digraph. This approach proved to be too slow, because for every link found in an entry, a verification query has to be made. The scan rate of this version of ek$iEdgeDump was less than 1,000 titles/day. Given the fact that the database contained more than 700,000 titles, the job would be completed in nearly two years. Clearly, another approach had to be adopted .

In the second version of ek$iEdgeDump, the focus is back on the entries instead of the titles. As one can recall from the description of the Entry class in ek$iAPI, one of the details of acquired from Ekşi Sözlük when an entry is extracted is the title the entry is placed under. Thus, we can produce a different table that looks like the EdgeData table described above that keeps information of the source and the destination vertices of the directed edge. The table, in the new approach, is produced by scanning the entries in the database (they reside in a table named Entries), parsing out the links that point to titles and writing the pair consisting from the name of the source title and the destination title to a table named EksiEdgeData without checking whether the destination title exists in the Titles table. This verification effort was the factor that slowed the first version down, and it can be handled without querying the database by ek$iVista (the details of how this is done are given in the section discussing ek$iVista). As the title data in the Entries table is stored in string format (not as integers; foreign keys related to title ID column in Titles table), the size of the EksiEdgeData table is significantly larger than that of EdgeData. ek$iVista uses the data from EksiEdgeData table, generated by the last version of ek$iEdgeDump.

Fig. 5: ek$iEdgeDump versions 1 and 2 in action

comp 491: report | ek$iDump

ek$iDump

The Problem: Coming up with a portable application to acquire Ekşi Sözlük entries and store them in a database.

Design: Although the final product of the project will be a graph depicting connections between Ekşi Sözlük titles, the connections arise from the content of the titles, which are, obviously, the entries. That is one of the reasons why ek$iDump is a tool for getting the entries rather than the titles. Another and maybe the prime reason for focusing on entries is that entries have unique integer IDs that allow them to be acquired one by one in a for-loop or a while-loop.

ek$iDump is, due to this nature of Ekşi Sözlük entries, at the level of complexity of a “Hello World” program. The program, designed as a console application, gets the starting ID and the terminal ID as its input, which are integer values. In a while-loop, beginning from the starting ID, if the entry with the given ID exists, it gets it from Ekşi Sözlük by calling Entry.GetFromEksi(ID) and writes the details of the Entry acquired to the database. The database of choice is a Microsoft Access file, because one does not have to set up a server for using it; even if you do not have Microsoft Access installed, one can obtain and install a package named Office 2003 Redistributable Primary Interop Assemblies and get on with using the database. Also, the data accumulated in the database is easily exportable to Microsoft SQL Server, which the other two sections of the project, ek$iEdgeDump and ek$iVista use. One always has to make the quantum leap from Microsoft Access to another pro-level RDBMS at some level, as Microsoft Access imposes a size limit of 2 GB on a database file. Note that although it is by no means final, the size of the database file generated in the course of the project exceeds 5 GB. An image showing ek$iDump in action is given in the figure below:

Fig. 4: ek$iDump in action, dumping entries