Saturday, May 30, 2009

Closure

Closure ozelligi Python, Scheme, Javascript gibi dillerde dinamik olarak fonksiyon yaratip o fonksiyonu parametre olarak gonderebilme/dondurebilme ozelligidir. Fonksiyon dinamik olarak bir "paket" halinde olusturulur ve olusturuldugu anda dis kapsamda (outer scope) olan degiskenlere erisebilir, ve bu paket gonderildigi yerde icindeki o degiskenleri hala kullanabilme ozelligini muhafaza eder.
def make_number_printer(n):
def number_printer():
print n
return number_printer

printer = make_number_printer(5)
printer()
Ustteki ornekte '5' sayisi ekrana basilacaktir.

Kaynak

Sunday, May 24, 2009

Linux ile Mikrofona Baglanmak

Linux uzerinde standart mikrofon ve ses geri calma araclari olan arecord ve aplay ile disaridan gelen sesleri bilgisayara aktarabilirsiniz.
arecord -d 1 -f dat
komutu bir saniye sureli olarak wav formatina uyumlu ses verisini ekrana basar. Bu bilgiyi bir wav dosyasina aktarabiliriz, ama bu kaydi ek araclar ile islemden gecirmek istiyorsak (mesela ses tanima uygulamalari icin) o zaman bir Python scripti ile isletebiliriz.
import os
output = os.popen('arecord -d 2 -f dat').read()
Su anda output String tipindedir ve bu String icindeki her karakter ses kaydinin bir parcasini tasimaktadir.
print len(output)
print type(output)
print output[1:10]
komutlari sirasiyla bu verinin uzunlugunu, tipini ve ilk 10 karakteri ekrana basar. Eger dosyaya yazmak istiyorsak
outfile = open("/tmp/out.wav", "w")
outfile.write(output)
Simdi aplay /tmp/out.wav komutu ile bu ses kaydinin dinlememiz mumkun. Degisken output icindeki veriyi Numpy, Scipy ile islemden gecirebiliriz; FFT (fast fourier transform) bu islemlerden sadece bir tanesi.

Friday, May 22, 2009

Python ve MySql

Bilimsel hesaplama (scientific computing) icin Python araclarini isledik. Bunlar SciPy, NumPy ve Matplotlib araclari idi. Isin veri tarafina bakarsak; Eger hesaplanacak veri Mysql gibi bir tabanda ise, bu tabandan verileri okuyabilmek gerekir. Bir hesap tipik olarak gereken tum veriyi hafizaya getirip sonra vektor bazli hesaplara tabi tutar. Islemcilerin gelecegi cok cekirdekli (multi-core) yonune dogru gittigine gore, hesaplarin paralelize edilip bir sekilde asenkron usulde isletmek te mumkun tabii.. Bazi Python araclari burada yardimci olabilir; En alt seviyede cekirdekler arasinda mesajlasma icin MPI standardi var mesela, ve burada yardimci olabilecek kutuphaneler mevcut. Bu konulara ileride girebiliriz.

Mysql'e baglanmaya gelelim. Bu alanda en iyi bilinen MySql-Python paketidir. Kurma yontemi oldukca standart, paketi indirin, acin, ve sudo python setup.py build ve install. Bu paketi kullanmanin iyi yontemi var, bir tanesi Mysql arayuzune bagli olarak, digeri ise standart Python DB-API arayuzu kullanarak. Biz ikisini de gosterelim, ama bizim tercihimiz "mecbur olunmadikca" standart arayuzdur, boylece yazilan kodlar diger tabanlar uzerinde de isler.
import _mysql

db=_mysql.connect(host="localhost",user="kullanici", passwd="",db="taban")
db.query("""SELECT count(*) from tablo""")
r=db.store_result()
print r.fetch_row()
DB-API usulu
import MySQLdb

db=MySQLdb.connect(user="kullanici",passwd="",db="taban")
c=db.cursor()
c.execute("""SELECT count(*) from tablo""")
print c.fetchone()

Wednesday, May 20, 2009

Seam ile Kullanici Idaresi

Seam pages.xml dosyasinda kullanicinin login durumu ile alakali komutlar kullanabilmemizi saglar. Bunlardan bir tanesi login-required ibaresidir; eger bir sayfa taniminda login-required tanimlamissak, kullanicinin login durumuna gore onu bir login sayfasina yonlendirmemiz mumkun olmaktadir. Kullanim soyle:
<page view-id="/sayfa.xhtml" login-required="false">
..
</page>
Peki Seam, eger kullanici login etmemisse hangi sayfaya yonlendirme yapilacagini nereden bilecek? O da pages.xml'in en tepesinde tanimli:
<pages login-view-id="/login.xhtml">
..
</pages>
Login edilmedigi durumunda ve sayfa.xhtml'e gitmek istedigimizde Seam, login.xhtml sayfasina gonderecek. Simdi; Seam'in "login edilip edilmedigini nasil anlayacagi" mekanizmasina gelelim. Bunun icin oncelikle bir Seam Action yazip bu Java kodunun gerekli sifre, vs. bilgisini form'dan alip veri tabanina baglanip tabanda bilgileri kontrol ettikten sonra, kullanici/degil kararini vermesini saglamamiz gerekli. Bu kod neye benzer? Bizim kodlarda soyle:

@Stateful
@Scope(SESSION)
@Name("userHandler")
public class UserHandlerBean implements UserHandler {

@In Identity identity;

@Out(required=false)
Person user;

public boolean authenticate()
{

// database'den User objesini al
if (user == null) {
return false;
} else {
identity.login();
return true;
}
}
Identity uzerinde login() cagirilmis olmasi onemli. Simdi Seam'e bu yontemi tanitmak icin WEB-INF/components.xml dosyasinda
<security:identity authenticate-method="#{userHandler.authenticate}"/>
Person objesinin Action icinde de-enjekte edildigini dikkat edelim. Eger ek olarak Person objesi kendi Java dosyasinda @Scope(SESSION) ile, bir oturum (session) nesnesi olarak tanimlanmissa, artik uygulamadaki herhangi bir anda herhangi bir sayfada #{user} nesnesini null olup olmama testine tabi tutarak ona bagli olarak degisik islemler yapabiliriz. Mesela bir baglanti, Web sitesinde login olup/olmamaya gore gozuksun/gozukmesin demek istersek;
<s:link view="/sayfa.xhtml" rendered="#{user == null}">Bir Baglanti</s:link>
Ayni karar mekanizmasini pages.xml dosyasinda navigasyon amacli olarak bile kullanabiliriz. Mesela
<page view-id="/sayfa.xhtml" ... >
<navigation from-action="#{someAction.filan}">
<rule if="#{user == null}">
<redirect view-id="/suraya.xhtml"/>
</rule>
<rule if="#{user != null}">
<redirect view-id="/buraya.xhtml"/>
</rule>
</navigation>
</page>
Not: Kullanici statusunun uygulama ortasinda degistigi durumlarda, Identity uzerinde once logout() sonra login() arka arkaya isletmek gerekli olabilir.

Saturday, May 2, 2009

Git ve Dosyalar

Git sistemi icinde dosyalar nasil idare ediliyor? Git'in onemli avantajlarindan bir tanesi dosyalari kontrol edisinde; oncelikle her commit edisinizde o commit noktasi tekil bir hash kimligi ediniyor; bu oldukca uzun bir kimlik ve git log komutundan alinabiliyor. Sonra herhangi bir anda git checkout HASH ile o commit noktasina gidebiliyorsunuz (eger son eklerinize geri donmek istiyorsaniz onlari da commit etmeyi unutmayin, ki sonra git checkout master ile geri donebilesiniz).

Bir commit noktasina gidince ne oluyor?

Git, idare ettigi dizin altindaki dosyalari tamamen degistirerek o commit anindaki hallerine donusturuyor. Bu, mesela, ClearCase sisteminden farkli. O sistemde, aslinda ici normalde bos olan bir dizinde "set view" gibi bir komutu isletince "network uzerinden" dizinin ici birdenbire doluyordu, daha dogrusu network uzerinden baska bir makinadaki bir icerige "isaret etmeye" basliyordunuz. Git gunluk isleriniz icin network'ten bagimsiz olmayi amacladigi icin bu yolu takip etmiyor. Checkout komutu sonrasi gercek, fiziki dosyalarinizi degistiriyor.

Nokta git (.git) dizini icinde bunu yapmasi icin gerekli tum bilgiye sahip. O dizin bir nevi sIkIstirilmis bir database gorevini gormekte. Isterseniz butun dosyalarinizi silin; nokta git dizini icindeki veriler ile iceriginizi sifirdan tekrar yaratabilirsiniz.

Git bu baglamda CVS, Subversion sistemlerinden de farklidir; CVS'te bir branch yaratip onun icerigine bakmak ayri bir dizin gerektirir. Git, branch'ler arasinda gidip gelmeyi hep ayni dizin icinde halleder. Dosya iceriginizi pat diye degistirir. Peki commit noktalari, branch arasinda gidip gelmek performansi etkileyen bir faktor olmaz mi?

Cogunlukla olmaz; cunku commit noktalari arasinda degisik olan genellikle birkac dosyadir, ve Git sadece bu dosyalari degistirmekle ugrastigi icin fazla performans bedeli odemez. Aslinda bir branch icin koca bir yeni dizin yapisi yaratmak daha pahalidir. Clearcase orneginde ise network uzerinden zaten bir bedel odenmekteydi, ve her an network'e bagli olma zorunlulugu ortaya ciktigi icin isin aksama olasiligi vardi.