Ruby Nesnelerine Kalıcılığı Öğretmek

Dünyada en çok sevilen programlama dili olduğu söylenen Ruby ile sunucu taraflı uygulama geliştirmek için elimizde RoR gibi kullanması çok kolay ve işlevsel bir arayüz var.

Peki ya masaüstü uygulamalarımız için Hibernate benzeri kalıcık araçları karşısında Ruby'de alternatif yok mu?

Tabii ki var. Og (Object Graph) ile Ruby nesnelerine nasıl kalıcı olacaklarını öğretmek çok kolay olsa da, bu makale ile daha kolay olacak.

Görüşler

eof
19 yıl önce

Rails'de kalıcılık aracı olan ActiveRecord'u Rails olmadan da uygulamalarınızda kullabilirsiniz.

How To Use Active Record Outside Rails [wiki.rubyonrails.com]

bm
19 yıl önce

Propaganda firsati varmis, FZcigim guzel bir orta yapmissin dokunmasam olmazdi. Ne zamandir firsat kolluyordum.

Bu tip isler nasil yapilir (CLOS icin Meta-object Protokolu kullanilarak genel 'persistent class' ornegi)

Andreas Paepcke. User-Level Language Crafting - Introducing the CLOS Metaobject Protocol. In Andreas Paepcke, editor, Object-Oriented Programming: The CLOS Perspective. MIT Press, 1993.

http://www-db.stanford.edu/~paepcke/shared-documents/mopintro.ps

(Ozet, biz aletleri verelim de kalicilik yapilan islerden sadece biri olsun). Ruby sevenler, yeni yetme putlara tapmayin, Lisp sizi bekliyor.

(Propaganda oldugunu soylemistim, yarin obur gun ben de Ruby iyi seydir dersem yuzume vurmayin.)

FZ
19 yıl önce

Hmm, bu kitap Bilgi'nin kitaplığında görünmüyor! (*) Hemen sipariş verelim de Türkiye'deki Common Lisp'e en çok destek veren üniversite kütüphanesi buna devam etsin ;-)

Bu arada gördüğüm kadarı ile propaganda mevsimi açılmış, şahsen bundan hiç rahatsız değilim hatta diyorum ki 2005-2006 döneminde neden çok acayip bir Ruby kitabı yayınlanmasın Türkiye'de ve neden bu kitabın satışları yine Türkçe bir Common Lisp kitabı ile yarışmasın? (İzin koparabilsek ve basacak yayınevi bulsak Practical Common Lisp'e talip olurdum ya neyse... ;-)

* http://library.bilgi.edu.tr/

FZ
19 yıl önce

Chaitin'in şu lafını çok seviyor ve sık sık hatırlıyorum:

"So why do I love LISP?! Well, the answer is, because it's really set theory, and all mathematicians love set theory!" (*)

"O halde neden LISP'i seviyorum? Cevabı şu, çünkü Lisp küme teorisidir ve bütün matematikçiler küme teorisini sever!"

Benim sorum: Neden ülkemizdeki matematik (ve matematik müh.) bölümlerinde Lisp gösterilmiyor programlama dili olarak? (Mathematica, MatLAB, vs. iyi güzel tamam ama neden Lisp gösterilmiyor!?)

* http://www.cs.auckland.ac.nz/CDMTCS/chaitin/lisp.html

bm
19 yıl önce

Kitabi ben de bilmiyorum. Toplanmis makaleler olsa gerek. Paepcke'nin makalesi iyi, okunmaya deger (verdigim URL'den indirebilirsiniz). Ozellikle AMOP kitabiyla gayet iyi gider. AMOP kitabinin bir kismi da acik:

http://www.lisp.org/mop/index.html

Tercume/kitap isine gelince, malesef bu konuda Apress ile konusmak lazim. Belki zamaninda uyanilsaydi (uyansaydim) Siebel ile anlasilip Turkce haklari aliabilirdi ve Turkcesi tamamen webe acik PDF sekline getirilirdi. Benim tercihim isleri dijital ortamda ve acik tutmak. Yalniz cok da hayiflanmayalim, su ana kadar ilgilenenlerin hepsi Ingilizce biliyor gozukuyorlar, digerleri icin de belki bir sebep olur yabanci dillerini ilerletirler. Tamamen Turkce'ye donmek icin bir iki baska kitabi ve belki en onemlisi Hyeprspec'i[1] cevirmemiz lazim. Bunlardan sonuncusu kotu yapilacagina hic yapilmamasi gereken birsey, iyi yapmak da kadro ve bilgi meselesi (maliyet demiyorum, paradan dolayi tikanmadik hic henuz, unutma). Hevesli insanlar eger devam edip bilgili hale gelirlerse ve arzu ederlerse yapilir.

Propagandist sapkami kaybettim, bir de baska birsey soyleyeyim: Common Lisp 'en iyisi', 'en ileri', 'en birsey' oldugu icin ogrenilmemeli -- bunlar dogru olmayabilir. Ondan ve kulturunden bi-haber olmak, o tarzi bilmemek (ESR'in da dedigi gibi) onemli bir eksiklik oldugu icin ogrenilmeli. Benim derdim herkesi lispci yapmak degil. Hakikaten hevesli ve ciddi arastirmaya yatkin insanlarin sadece hasbelkader dogmus olduklari memlekette bir bilgisayar bilimi gecmisi olmamasi yuzunden derinden pekcok seyi etkileyen bir dilden, ve zamaninda (belki hala) onemli beyinleri etrafina toplamis bir kulturden habersiz kalmamalarini istiyorum. Buna 80lerde 90larda memleketteki imkanlar musait degildi. Simdi musait. (Haa bir de benim kolayima geliyor, o da var!).

[1] http://www.lispworks.com/documentation/HyperSpec/Front/index.htm
veya apt-get install hyperspec

ahmetaa
19 yıl önce

Ruby iyi guzel hos ama bir haftada 4 tane baslik vermek (ustelik haberler aslinda eski ya da harci alem seyler) biraz kabak tadi vermiyor mu?

FZ
19 yıl önce

Yaşasın pozitif ayrımcılık! Java'cılar pek hoşlanmıyor bundan galiba? ;-)

Şaka bir yana, bir de şöyle düşünsek: En az bir (ve tahminen daha çok) FM üyesi var ki Ruby'den müthiş etkilenmiş, heyecanlanmış ve buraya yazacak, küçük de olsa haber, yazı, vs. çevirecek kadar motive olmuş; bu heyecana kayıtsız kalmalı mıyız?

En azından dil savaşları tanrı var mı yok mu ya da evrim var mı yok mu tartışmasından daha eğlenceli.

ahmetaa
19 yıl önce

Eh hedef java olunca biraz sesimi yukselttim (Ruby programcilari nedense JavaBlogs sitesinde bir ara epey cirit atmisti. firtina gibi, esti ve gecti..).
Haklisin FZ, belki biraz hizlica ve dusunmeden yazdim yaziyi.. gozlemim su ki, bilgsayar dilleri ya da teknolojilerin birbirlerine karsi olan ustunlugu ne yazik ki cogu zaman "hello world" turu uygulamalar, satir sayisi, ya da yarim yamalak bir kac fikir ya da uygulama uzerine gosterilmeye calisilir. Oysa isler cogu zaman gorundugunden cok daha karisiktir. Her arac her probleme uymaz, hic bir teknoloji de aslinda sihirli degnek olmaz.. Ornegin, O/R mapping. Her seye deva olmadigi gibi sadece iki tip veri tabanina basit ekleme-guncellemeden ibaret degildir. Ornegin varolan bir banka veri tabanini O/R yapiya donusturme isinin yuz astarindan pahaliya gelebilir. Ya da kullandiginiza arac sizi Oracle ile yari yolda birkabilir.
Arkadasimizin heyecanina saygi duyuyorum.. Ama yarin oburgun biri cikar da bak Python'da da bu var, iste su makale.., aha Java'da IBatis var, daha iyisini yapar diye birbirini yiyebilir ona gore ;)

ttk
19 yıl önce

Sahi yahu Python da var netekim :)
Hem bir de Lisp öğrenecektim sözde.
Biraz Lisp'i söküp ortalığı karıştırsaydık iyi olacaktı, söz bir gün sökersem bunu yapmaya çalışacağımdır.

Bu arada Python iyidir haaa :)

FZ
19 yıl önce

Şimdi tabii ki gerçek hayatta (!) işler o kadar basit değil, basit ekle çıkar, güncelle mevzularının ötesinde şeyler var, aynı anda birçok programcının çalıştığı çok büyük, kurumsal projeler var, var da var... doğru ancak şu noktayı atlamayalım, bir işi ne kadar az sayıda satırla, ne kadar az kod yazarak yaparsam benim için o kadar iyi! Vakti zamanında SQL fikri ortaya atıldığında pek çok böyyük bilgisayarcı gülmüş dalga geçmişti, olur mu öyle dil yahu, bilgisayara neyi nasıl yapacağını adım adım anlatman gerekir, bu incelikli bir iştir, var mı öyle bir iki satırda bir sürü tablodan veri tarayıp bunları birleştirmek, vs. Oturacaksın prosedürel ve karmaşık algoritmalar, optimizasyonlar yapacaksın, vs. 2005 yılında baktığımızda ise SQL fikri ile dalga geçen bilgisayarcıların adını bilmiyoruz ama veritabanı sorgulama dendi mi şartlı refleks olarak hemen herkesin SQL diline göndermede bulunduğunu biliyoruz, bu çok önemli bir nokta!

Bu bakımdan ne kadar az yazarak ne kadar çok iş halledebiliyorsak o kadar iyi derim ve piyasanın (!) desteklediği yaklaşımlara alternatif olan şeylere de mutlaka göz atmaya, anlamaya çalışırım. Unutmayalım ki Galileo zamanında da bir çoğunluk vardı ve bugün biz o çoğunluğa bakıp, allah allah neden öyle düşünmüşler ki diyoruz. Şunu da unutmamak lazım, popülarite her şey mi demek? Birileri bir şeylere yatırım yapıyor, yani Microsoft olmasa VB'nin esamesi okunur muydu? Su gibi para akıtılıp desteklenmese sadece camia desteği ile Java bugün bulunduğu noktada olur muydu, vs. vs. Gerçekten de çoğunluğun rasyonel davrandığından ve en iyiyi seçtiğinden emin olabilir miyiz? 1000 şirket bunu seçti o zaman en iyisi, en pratiği bu olmalı cümlesini söylerken biraz dikkatli olmak bize çok mu zarar verir?

Basit, Hello World türü uygulamalara gelince, bakın mesela burada Lisp'ten bahsederken, Common Lisp filan derken hep Practical Common Lisp diye bir kitaptan örnek veriyoruz ki yazarı BEA'da da çalışmış (çalışan?) sağlam bir Java programcısı aynı zamanda. Bu adamın kitabındaki 3. bölüme bakın, giriş örneği olarak verdiği şey Hello World mü yoksa ötesi mi, bunu bir inceleyin:

http://www.gigamonkeys.com/book/

Bu örneği verdim çünkü görüldüğü gibi aksi örnekler de mevcut, herkes öyle HEllo World örneği basitliğinde örnekler vermiyor.

ahmetaa
19 yıl önce

Bu konuda cok hemfikir degiliz. Oncelikle SQL, SQL cok ust seviye, ve kendi problem uzayi icin olduka iyi bir cozum. Yani ben SQL'e camur atanladan degilim. Ama SQL kodunun test edilebilirligi ya da nesneye yonelimli bir disipline uygulanabilirligi oldukca dusuk. o nedenle bugun yazilim kodu icinde SQL kullanimindan, mumkun olan yerlerde kaciniyorum. Neyse, konu aslinda o degil. asil farkli dusundugum nokta su cumleniz:
"doğru ancak şu noktayı atlamayalım, bir işi ne kadar az sayıda satırla, ne kadar az kod yazarak yaparsam benim için o kadar iyi! "
Kesinlikle katilmiyorum. Bu cumle ancak kisa komut satiri, script turu yazilimlar, tek basina gelistirilen projeler ya da bir kere yazilip bakimi yapilmasi gerekmeyen projeler icin mantikli. Ne yazikki bu saydigim alanlar yazilim pazarinin belki %1'ini olusturur. kodun anlasilirligi, test edilebilirligi ya da genisleyebilirligi her zaman kodun boyutundan once gelir. Ve bu saydiim seyler genellikle kod boyutunu arttirici yan etkilere sahiptir (her zaman degil).
Dillerin populerliginin dilin asil gucunden once degerlendirildigine de katiliyorum, yani bir yerlerde tozlanmis ya da bir elin parmaklari kadar akademisyen tarafindan kullaniln VB ya da Java'dan cok daha yetenekli diller vardir. Ama bu gercekleri degistirmiyor. VB'ye bir sey diyemem ama Java benim icin "yeterince" iyi. Bir teknoloji yeterince iyi ise ve milyarlarca dolarlik bir pazara sahipse, nedne takip etmeyeyim? ben akademisyen de degilim, yani oturup atiyorum Ruby ya da Lisp ile kasmam bana verimlilik acisindan bir sey kazandirmiyor ki? Adam gibi IDE yok, her konuda kutuphane bulamazsin, ya da elindeki kutuphaneler her problemini cozmez.. ne yapayim ayni isi 100 satir degil 50 satirda yazmissa? Getter-Setter yoklugu ya da Casting'in varligi cok mu onemli? Checked Exceptions ya da Operator Overloading yoklugu zararli mi? Hayir bunlarin hepsi zamaninda dusunulmus ve kodun kotuye kullanimini engellemek icin yerine gore kod boyutunda fedakarlik edilerek tasarlanmis. Hem IDE'ler artik bu isleri yillardir otomatik yapiyor, benim icin try-catch blogu yazmak iki tusa basmaktan obaret, 10 tane getter setter metodu olusturmak icin Alt+Insert ve ok tuslarina bir kac kere basmam yeterli. kisa bir projeyi bit Python ya da Ruby programcisi ile ayni hizda, Buyuk bir projeyi ise daha hizli yazilabilecegini iddia ederim. eger yazilan kod adam gibi anlasilir degilse ya da testi yapilmamisa bence kodun kisa olmasi rahmet degil, lanettir..
Lisp konusunda bir sey diyemem. Dilin guclu ve farkli oldugunu biliyorum ama detaylarini bilmiyorum. ama akademik dunya haric kullaniminin az oldugunu biliyorum (ne yazik ki), bu benim icin onemli negatif bir nokta..

bm
19 yıl önce

Hayat kazanma baglaminda dediginiz dogru. Isinizi en rahat nasil yapacaksaniz, yahut secme sanisiniz olmayan parametreler dahilinde isinizi en verimli nasil yapabilecekseniz oyle yapmaniz en akilci yol. Bu bakimdanm analizinize katiliyorum.

Katilmadigim nokta su:

Adam gibi IDE yok, her konuda kutuphane bulamazsin, ya da elindeki kutuphaneler her problemini cozmez.. ne yapayim ayni isi 100 satir degil 50 satirda yazmissa?

Adam gibi IDE konusunu bir tarafa birakalim, 'her konuda kutuphane bulamazsin' ifadesindeki gizli anlami dusunelim. Kutuphane bulunabilen konular insanlarin evvelce dusundugu, cozdugu, uzerinde mutabakat olan ve/veya stadart koyucuyu tatmin eden bir ortak kullanim tarzinin olgunlastigi konular. Alanimiz bunlardan ibaret degil. Mesele 100 satiri 50 satira indirmek degil, yepyeni bir alanda dili probleme uydurma kabiliyetine sahip olmak, kimsenin gitmedigi yerlere el yordamiyla giderken deli gomlegine benzer birsey giymemis olmak. Madalyonun obur yuzundeki dusunce tarzi bu.

Hayir bunlarin hepsi zamaninda dusunulmus ve kodun kotuye kullanimini engellemek icin yerine gore kod boyutunda fedakarlik edilerek tasarlanmis.

Java'dan bahsediyorsaniz, bunu hazirlayanlar ortalama bir C/C++ programcisini en acisiz sekilde (yani korkutmadan) biraz daha modern bir dile nasil gecirip nasil dilimizi populer hale getiririz diye dusunduklerini acik veya kapali soyluyorlar. Steele bir de

And youre right: we were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp. Arent you happy?[1]

Filan gibi ifadelerle bir kalabaligi oraya buraya cekistirdiklerini acikca soyluyor. Piyasa sartlari, ve kutuphane vs. sebeplerden dolayi bu tip dilleri tercih etmek gayet makul olsa da, 'nicin oraya buraya goturulenlerden oluyorum da goturenlerden olmuyorum' demek de insanin aklina geliyordur herhalde? Sadece akademik yaklasim degil insanlari alternatifleri ogrenmeye iten demek istiyorum. Yoksa yazdiklariniz calisan bir programicinin is hayatina bakisi acisindan kesinlikle kusur bulunacak seyler degil.

[1]
http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg04045.html

Görüş belirtmek için giriş yapın...

İlgili Yazılar

Yazılım Geliştirmede Kodlama Stili ve Gösterimin Önemi

maat
24 Mayıs 2005, 8 dakika okuma süresi

Bu yazımızda program yazımında kodlama stilinin öneminden bahsedeceğiz. Geliştirilen yazılımlarda bulunması gereken özelliklerden birisi de "okunabilirlik"tir. İyi bir program sadece yazan kişinin baktığında neyin, nerede nasıl yapıldığını ya da değişkenlerin türlerini anlayabildiği program değil, aksine, kullanılan dilin genel kabul görmüş yazım kurallarına uygun olarak hazırlanmış adeta bakıldığında "şiir gibi okunabilen" programdır. Yazımızın bundan sonraki bölümlerinde kullanılan çeşitli stilleri anlatarak ve örneklerle destekleyerek konumuzu daha da açacağız. Ancak konunun genişliği sebebi ile ancak anahtar noktalara değineceğiz. Anlatılanların daha geniş açıklamaları için kaynaklara bakılabilir.

Veritabanı Teknolojilerindeki Yenilikler

FZ
12 Nisan 2002, 3 dakika okuma süresi

Veritabanı ve bununla bağlantılı çözümler deyince son 20-25 yıldır çoğunluğun aklına gelen terimler aynıdır : SQL, ilişkisel veritabanı yönetim sistemi (markadan bağımsız), ODBC ve bunlara C++, Visual Basic, JAVA gibi dillerle erişmek ve sonuç çözümü programlamak.

Markalar değişir, işletim sistemleri değişir, işin içine Internet girer, sistemler biraz daha hızlanır, fiyatlar değişir ama temelde öyle radikal değişiklikler olmaz... diye düşünüyordum ben bugüne kadar ancak bu düşüncemi değiştiren birkaç şirketin web sayfalarına göz atıp bir miktar inceleme yaptıktan sonra öğrendiklerimi sizinle paylaşmaya karar verdim.

Gmail´i Genel Depolama Alanı Olarak Kullanın!

FZ
5 Eylül 2004, 1 dakika okuma süresi

GmailFS size Gmail hesabınız için ayrılmış Gmail disk alanını "mount" etmenizi sağlayıp sonra da bunu genel bir disk alanı gibi kullanmanıza izin veren bir tür sanal dosya sistemi sunar. GmailFS bir Python uygulaması olup FUSE isimli altyapıdan ve libgmail fonksiyon kitaplığından faydalanmaktadır.

GmailFS, "read", "write", "open", "close", "stat", "symlink", "link", "unlink", "truncate" ve "rename" gibi işlemleri destekler. Bu da şu demektir, Gmail hesabınız için size ayrılmış uzaktaki disk alanı sanki kendi makinanızdaymışçasına ve sanki normal bir disk alanı gibiymişçesine " cp", "ls", "mv", "rm", "ln", "grep", vb. komutları çalıştırabilirsiniz.

Meraklısı GmailFS ana sitesine bakabilir.

Bu yazılıma dikkatimi çeken Can Burak Çilingiroğlu'na teşekkürler.

Xen: VMware® için özgür alternatif

roktas
3 Aralık 2004, 1 dakika okuma süresi

VMware`in özgür ve üstelik daha hızlı alternatifini buluyoruz galiba. Bu haber OSNews`de dikkatimi çekti. Xen, Cambridge üniversitesi Bilgisayar Labortuvarlarında geliştirilmiş özgür lisanslı bir sanal makine yazılımı. İhtiyaç sahipleri bilirler, sanal makine yazılımları özellikle önyükleme ve sistem kurulumu yazılımlarının test edilmesinde, kirlilik oluşturmadan farklı işletim sistemlerinin denenmesinde çok yararlıdır. VmWare`in mevcut alternatifleri Bochs ve Qemu yeterli performansa sahip değiller ve böyle bir şeye hakikaten ihtiyaç vardı. (Qemu Bochs`dan çok daha iyi durumda, fakat VmWare ile karşılaştırıldığında maalesef o da yavaş kalıyor.) Xen özel tekniklerle (?) böylesi bir yüksek performansa ulaşabiliyor. Daha şimdiden Redhat, Novel, HP vb. bu projeye üşüşmüş durumdalar. Xen`in Linux çekirdek kod tabanına eklenmesi de gündemde. Ha unutmadan, anladığım kadarıyla teknik olmaktan ziyade yasal nedenlerden dolayı Xen'de sanal Windows çalıştırmak mümkün değil henüz. Ama ekran görüntüleri NetBSD`yi deneyebileceğinizi söylüyor. Bu güzel :-)

İşte geleceğin bilgisayarının arayüzü

nehuse
8 Nisan 2004, 1 dakika okuma süresi

Sun'ın bilgisayar masaüstü ortamı kavramında devrim yaratacak bu yeniliği henüz geliştirme aşamasında.

Bu yeni kavram, iki boyutlu olarak kullandığımız masaüstünün yerine, üç boyutlu, içinde dolaşabildiğimiz, simgelerimizi, pencerelerimizi, nesnelerimizi yerleştirebildiğimiz sanal bir ortam sunuyor.

"Looking Glass" adı verilen bu projenin yalnız Linux sistemler üzerinde çalışan prototipi mevcut. 2004 yılı ortalarında ilk beta sürümün çıkması planlanıyor.

Sun LGP sayfası:
http://wwws.sun.com/software/looking_glass/index.html

Basın toplantısının videosu: (quickTime)
http://webcast-east.sun.com/archives/GSN-1312/GSN-1312_forjds.mov