Luckily, Django comes with full documentation and uses Sphinx. Unfortunately though, they don’t provide compiled CHM files on the download site. You have to download the django-version-tar.gz, install sphinx on your system, fix a couple of bugs in the layout and themes, generate htmlhelp project, install HTML Help Workshop, and only then you can have your baked CHM file. I’ve been there..

So, since I’ve already compiled the file, put it somewhere here.

You can download the Django 1.2 Documentation CHM file here: Djangodoc-1.2.chm

But this image rotation problem is already solved with Exif. Exif contains an orientation property, which can be used to correctly display the photos on a digital viewer. New cameras, and viewers support the use of this property. So I thought it would be better if I can embed the Picasa rotation information into the Exif headers of photos.

After trying several tools, (even one of them doubling the size of the original photo, while modifying the Exif property ??!) I have settled on using Exiv2.

Then I coded the following simple, short Python script to embed Picasa rotation information to photos:

# Embed Picasa rotation information to EXIF Image Orientation tag.
# Uses Exiv2 command line utility from http://www.exiv2.org/.
#
# Serkan Kenar, 2010, Ankara.

import subprocess

lines = open(".picasa.ini")

filename = None

rot2ori = { 0: 1,
            1: 6,    # left
            2: 3,    # bottom
            3: 8 }   # right

for line in lines:
    if line[0] == '[':
        filename = line.strip("[]\n")
        continue
    (action,param) = line.split("=")
    if action == "rotate":
        yon = int(param[7:8])
        try:
            subprocess.call(['exiv2',
                             '-k',   # preserve timestamps
                             '-v',
                             '-Mset Exif.Image.Orientation %d' % rot2ori[yon],
                             filename])
        except OSError:
            print "Exiv2 is not found on the path!"
            exit

You should run this script in photos folder with a “.picasa.ini” file. Make sure that exiv2 command-line utility is in your path.

Tez yazmak, yapmaktan çok daha zor bir iş olduğu için, bu yolda bana destek veren akademik danışmanıma, eşime ve dostlarıma teşekkür derim. Bunu aslında teze de yazmıştım, ancak buradan da tekrarlamak istedim.

Aslında ingizlizcesinde bir aliterasyon yapılmış (Plato and a Platypus walk into a bar…) ancak türkçeye çevirince o aliterasyon kaybolmuş. Kitap fıkralar eşliğinden sıfırdan başlayıp, felsefenin belli başlı konularına değiniyor: mantık, metafizik,din felsefesi, varlık, varoluşçuluk, kahroluşçuluk, vs.. Kitap çok akıcı, çok eğlenceli fıkralar var. Sıkılmadan okunuyor ki çoğu felsefe kitabı için zordur bu.. Bunu da zaten bir felsefeye giriş olarak okumak da fayda var.. Tam bir boş zaman kitabı, tavsiye ederim.

Sonucun değişmemesi, çalışma zamanında yanlış giden bir şeylerin olduğu konusunda şüphelendiriyor. Hemen GDB’yi çalıştırıyoruz.

	gdb ./mysql_bug
	break connect

connect() metodunun çıktısını gördüğümüzden oraya bir breakpoint ekledim. run diyerek çalıştırıyoruz ve breakpoint’e takılıyor. Adım adım işletelim.

	next
	n
	<enter>

O da ne?? Tekrar connect()’e geldi. hmm, bt ile bir stack trace alalım.

	(gdb) bt
	#0  connect () at mysql_bug.c:16
	#1  0xb7e6f766 in my_connect () from /usr/lib/libmysqlclient.so.15
	#2  0xb7e70338 in mysql_real_connect () from /usr/lib/libmysqlclient.so.15
	#3  0x080485f0 in connect () at mysql_bug.c:16
	#4  0xb7e6f766 in my_connect () from /usr/lib/libmysqlclient.so.15
	#5  0xb7e70338 in mysql_real_connect () from /usr/lib/libmysqlclient.so.15
	#6  0x080485f0 in connect () at mysql_bug.c:16
	#7  0x08048644 in main () at mysql_bug.c:34

İlginç bir şekilde mysql_real_connect()’ten sonra, tekrar connect() metodumuza geliyor. MySQL kütüphanesi bizim yazdığımız bir fonksiyonu neden çağırsın? Artık mesele anlaşılmış gibi olsa da biraz daha debug etmeye devam edelim. “ignore 1 1010″ komutuyla GDB’nin breakpoint’imizi 1010 kez gözardı etmesini sağlıyor ve devam (cont) ediyoruz. Tekrar breakpoint’e takıldığımızda bir bt komutuna bakın.. Artık problem daha da kendini belli ediyor. Tüm stack tekrar tekrar çağırılmaktan dolmuş:

	#3034 0xb7e6f766 in my_connect () from /usr/lib/libmysqlclient.so.15
	#3035 0xb7e70338 in mysql_real_connect () from /usr/lib/libmysqlclient.so.15
	#3036 0x080485f0 in connect () at mysql_bug.c:16
	#3037 0xb7e6f766 in my_connect () from /usr/lib/libmysqlclient.so.15
	#3038 0xb7e70338 in mysql_real_connect () from /usr/lib/libmysqlclient.so.15
	#3039 0x080485f0 in connect () at mysql_bug.c:16
	---Type <return> to continue, or q <return> to quit---
	#3040 0x08048644 in main () at mysql_bug.c:34

Dinamik Bağlanma (Dynamic Linking)

Artık bulmacanın cevabını verebiliriz. Bir şekilde fonksiyonumuza verdiğimiz masum “connect” ismi, MySQL kütüphanesinde de tanımlanmış ve mysql_real_connect() fonksiyonu tarafından kullanılıyor. Biz mysql_real_connect’i çağırdıkça o da bizi tekrar çağırıyor. Bu iç içe durum 1022 kez tekrarladıktan sonra mysql_real_connect hata dönüyor ve o ana kadar çağırılan tüm metodlar hata vererek tek tek çıkıyor.

Peki, bizim kendi yazdığımız bir fonksiyon nasıl olur da MySQL kütüphanesi tarafından çağırılabilir? (Bence esas yanıtlanması gereken soru bu, yoksa problemi deneme yanılma yaparak çözmek ve bir daha arkanıza bakmadan kaçmak mümkün. Ama gerçek bir coder kaçmaz, üzerine gider.)

Programımız MySQL kütüphanesine dinamik olarak bağlanarak derleniyor. Dinamik bağlanma yönteminde çalıştırılan program hangi kütüphaneleri kullandığını bir tabloda ve bu kütüphanede kullandığı metodları da başka bir tabloda tutar. Bu listeyi görmek için “ldd” komutunu kullanabiliriz. Mesela bizim programımız için ldd çıktısı şu şekilde olmaktadır:

	# ldd mysql_bug

	linux-gate.so.1 =>  (0xb8092000)
	libmysqlclient.so.15 => /usr/lib/libmysqlclient.so.15 (0xb7e96000)
	libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d33000)
	libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7d19000)
	libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 (0xb7ce7000)
	libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0xb7cce000)
	libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7ca8000)
	libz.so.1 => /lib/libz.so.1 (0xb7c92000)
	/lib/ld-linux.so.2 (0xb8093000)

Programımızı çalıştırdığımızda Linux altında ld-linux.so kütüphanesi bu tablodaki kütüphaneleri bağlamaya başlar ve programımızı çalıştırır. (Aynı shell scriptlerinin ilk satırında hangi interpreter tarafından çalıştırılacağının yazması gibi, tüm çalıştırılabilir dosyaları da aslında ld-linux.so “çalıştırır”. /lib/ld-linux.so’ya programınızın adını parametre verin ve olanları görün ) Öncelikle tüm kütüphaneler araştırılır. ld-linux, /etc/ld.so.config dosyasındaki sıralamaya göre kütüphaneleri arar. Bulunamayan bir kütüphane olduğunda program çalışması hata ile sonlanır (hatta teknik olarak hiç başlamaz..) Genelde aksi belirtilmedikçe fonksiyonlar tembel (LAZY) bağlanır. Yani bir fonksiyon kullanılmadıkça performans açısında bu arama/bağlama işlemi masraflı bir işlem olduğu için bağlanmaz.

Program çalışması sırasında daha önce bağlantısı sağlanmamış bir fonksiyon kullanımı ile karşılaşıldığında hemen bir dinamik bağlanma işlemi başlar. Aşağıdaki sırayla fonksiyon bulunmaya çalışılır:

1. mevcut program içinde
2. LD_LIBRARY_PATH çevre değişkeniyle verilmiş olan kütüphaneler arasında
3. programın dinamik bağlı olduğu kütüphaneler arasında (ld.so.cache’e bakarak)
4. programın dinamik bağlı olduğu kütüphanelerin önce /lib’te sonra /usr/lib’te bulunanları arasında

Gördüğümüz gibi, bilinmeyen bir fonksiyon hangi kütüphaneye ait olursa olsun, bu sırayla araştırılıyor. MySQL kütüphanesine ait mysql_real_connect fonksiyonu bağlandıktan sonra, çalıştırıldığında içindeki connect() fonksiyonu için arama başlatılıyor ve ilk sırada bizim programımız içinde bir aday bulunduğu için bağlantı burada sonlanıyor. Ondan sonrası yukarıda karşılaştığımız duruma neden oluyor.

Yukarda kendi programımızı debug edebilmiştik. Peki, bu dinamik bağlantı işlemini nasıl görebiliriz ve hataları tespit edebiliriz? Kütüphanenin çevre değişkenleri sayesinde çalışmasının etkilenebildiğini LD_LIBRARY_PATH’ten biliyoruz. Aynı şekilde LD_DEBUG çevre değişkeniyle de debug çıktısını açabilmek mümkün. Burada kullanılabilecek çeşitli parametreleri man ld-linux ile veya LD_DEBUG=help <herhangi_bir_komut> ile görebilirsiniz. Şimdilik LD_DEBUG=all ./mysql_bug diyerek programımızı çalıştıralım ve yukardaki paragrafta anlattığımız süreci canlı canlı görebilirsiniz. Çok uzun bir çıktı veriyor ama ilk satırlarını okumak fikri anlamanız açısından çok öğretici ve faydalı.

MySQL kütüphanesinde neden böyle çok yaygın kullanılabilir bir fonksiyon ismi vardır, kim bilir? Ama özensiz alınan kararlar maalesef böyle sorunlara neden olabiliyor. Fonksiyonlara, değişkenlere isim vermek sorumluluk ister.

Aslında bu yöntem çok yaygın olarak programların hafıza tahsis (memory allocation) hatalarını tespitte kullanılabilmekte. Örneğin malloc/realloc/free fonksiyonlarını yeniden tanımladığımız bir kütüphane yazarak, diğer programları test etmek mümkün (üstelik tekrar derlemek gerekmeksizin..)

Sonuç: Ufak gibi görünen bir sorun, üzerine düşüldüğünde farklı kavramların tekrar üzerinden geçmemizi ve hafiften paslanmış debugging marifetlerimizi hatırlamamızı sağladı.

Bunun üzerine fonksiyon ismini my_connect() yaparak tekrar denedim. Bahtsızlığın bu kadarı, bu seferde derleme aşamasında bir hatayla karşılaştım. Bu fonksiyon yine (!!) MySQL tarafından tanımlanmış. Başlık dosyalarında daha farklı tanımlandığı için daha derleme aşamasında hatayı görmek mümkün olabildi. Bu sorun kokeksibir’in yorumunda bahsettiği durum..) Neyse bunu geçebilmek en azından daha kolay.

Keyifli kodlamalar..

Not: WordPress’in başlık dosyalarının noktasından önce boşluk koymasını engelleyemedim. Muhtemelen noktadan önce boşluk bırakmayanlardan olduğumu sanıyor.

#include <stdio .h>
#include <stdlib .h>
#include <mysql /mysql.h>

MYSQL *mysql;

int connect()
{
    mysql = mysql_init(NULL);
    if (mysql_real_connect(mysql,
               "localhost",
               "username",
               "password",
               "database",
               0,
               NULL,
               0
              ) == NULL)
    {
        fprintf(stderr, "Unable to connect to database\n");
        return 0;
    }
    return 1;
}

int main()
{
    if (!connect()) return 1;
    // bir seyler...
    return 0;
}

Bunları çektikten sonra, bir yazıya denk geldim. “10 metre çapınızda en az 10 harika fotoğraf çekebilirsiniz” temalı bir çalışma ya da yeni bir ilham kaynağı. Aklınıza gelen bir fikir yoksa, çevrenize bakmak için bir sebep. Aşağıdakiler de buna benziyor. O anda konserin ortasında yerimi değiştirmeye uğraşmadan, gördüğüm açıdan çektim..

Albüm: Yeni Türkü konseri – ODTÜ Bahar Şenlikleri (2009)

Son projemizde de testlerimizi Eclipse altında geliştirmeye karar vermiştik. Burada uzun uzun yazmayı, hatta resmini/videosunu çekerek göstermeyi düşünmüştüm ama buna gerek olduğunu düşünmüyorum. Eğer siz de Eclipse altında çalışmak zorunda bırakılan acınacak durumdaki geliştiricilerdenseniz, verildiğini düşündüğünüz özelliklerin nasıl daha “kullanılabilir”, “hızlı” ve “akıllı” geliştirildiğini görmek için Intellij IDEA’yı bir deneyin.

Mesela bir auto-complete, benim yazma hızımdan daha yavaş çalışıyorsa, ve üstüne akıl edip kullanmayı düşünebileceğim metodları, sınıfları getirmiyorsa ne işe yarar? Veya, IDE dosyaların haricen değişikliklerinin otomatik olarak farkına varamıyor da eski halleriyle çalışmaya devam ediyor, illa F5 istiyorsa, ne kadar akıllıdır? Arayüz, menüler ve rasgele düzenlenmiş kısayollar -bir programcının elinden çıktığı çok belli-, kullanılabilirlik uzmanlarınca düzenlenmediyse, ne kadar kullanışlı olabilir? Bir kısayolları silsilesi düşünün, çalıştırmak veya debug etmek için kullanılan, her bağlam için ayrı bir tuş tanımlanmış.

Sanırım tüm bu başarısız kullanılabilirlik ve yetersizliklerin nedeni, Eclipse geliştiricilerinin OSGi framework’üne uyumluluk ve altyapıya verdikleri önemden kaynaklanıyor. Eclipse Framework’ünü yine benzer işlerimizden biri için incelemiştik ve uygulama geliştirmek için Java’nın yıllardır beklediği sağlam bir altyapıyı sağladığını görmüş, beğenmiştik. Plugin yapısı, otomatik ağ güncellemeleri, yardımlar ve daha bir çok hazır çözüm uygulama geliştirmeyi çok kolaylaştırıyor. Bir arkadaşın da dediği gibi, “yakında tüm IDE’ler Eclipse tabanlı olacak.” Aslında her tür uygulama için kullanılabilir ama Java’nın da bir yeri var.

Açık kaynak kodlu olması ve bedava olması, tüm bu kusurlarını kapatamıyor ve bu kadar kötü bir araçla çalışmayı kabullenilebilir yapmıyor. Eclipse’in yıllar içinde neden olduğu en büyük kötülük bedava olması ve her özelliği öyle veya böyle barındırması nedeniyle daha iyi araçlara ayrılabilecek “masrafları” yüksek gibi göstermesi. Halbuki Intellij IDEA geliştirici başına verilen parayı son kuruşuna kadar hakeden bir yazılım..

Eclipse’cilere tavsiyem, testerenizi bilemenin hatta motorlu testere kullanmanın tam zamanı..