Deliliğe Dair
Bugün bir deliyle karşılaştım "Abe bi cigara ver bea, bi cigara". Baktım adam samimi samimi sigara istiyor, kıvırmak yok, estek köstek yok, direk sigara istiyor; verdim. Bir teşekkür bile etmedi, yalakalanmadı, çekti gitti.
Kafama takıldı sonradan, etrafımdaki bir çok insana göre bu delide bir samimiyet var. Sözünde yalan yok, dosdoğru konuşuyor, nokta kadar menfaat için virgül gibi eğilmiyor. Adam gibi istediğini söylüyor. Amacını biliyor, gerekeni yapıyor, hedefine ulaşıyor.
Hakikaten deliler dünyadaki en dürüst insanlardır. Yalan söylemezler. Kendilerini olduklarından zengin, kültürlü, zeki, bilgili vs. göstermeye çalışmazlar. Yaltaklanmaz, yağ çekmezler.
Prensip sahibidirler, bildiklerinden vazgeçmezler.
Özgürdürler, kimse onlara ne yapacağını söyleyemez. İsterlerse yaparlar, istemezlerse yapmazlar. Canlarının istediği yerde gezerler. Kafaları bozulursa söver-sayarlar. İstedikleri gibi giyinirler, genelgeçer kaideleri iplemezler. Nezaket yahut şu bu gereği konuşmaz, dosdoğru bildiklerini okurlar.
Delilere ısınmaya başladım. Bişeyler var bu adamlarda. Yoksa bunlar veli mi?
ufukyayla 07.03.2005 13:14:11 Yorumlar [1]
VT de Kullanılan Alanı Bulmak
Örneğin bu sitede kullanılan site içi iletilerde (PM-ÖM) bir üyenin aldığı ve
gönderdiği iletiler için kullandığı alanı hesaplatmak için aşağıdaki kodu
kullandım. Burada verdiğim kod sadece alınan iletiler içindir. Diğerinide
aynı mantıkla yazmak zor değil zaten.
Function IletiKullanilanAlanGelen()
Dim
RsF, SqlF, xS
SqlF="select konu, metin from ileti_ileti where
(alici='" & Session("kod") & "' and asil=false)"
Set
RsF=Server.CreateObject("ADODB.Recordset")
RsF.Open SqlF, Conn,
adOpenStatic, adLockReadOnly, adCmdText
If RsF.Bof=False And
RsF.Eof=False
Then
xS=RsF.GetString(,,"x","x")
Else
xS=""
End
If
IletiKullanilanAlanGelen=Len(xS)-(RsF.RecordCount*2)
RsF.Close
Set
RsF=Nothing
End Function
Alıcısı aktif üye
[Session("kod")] olan iletilerden silinmemiş olanlarının sadece konu ve
metin alanlarını seçtirdim. Bu alanlardaki bütün veriyi GetString ile xS
adındaki bir değişkene atadım. Bu değişkenin boyutu üyenin gelen iletiler için
kullandığı alandır. GetString yaparken hata vermesin diye araya "x" koyduğumdan
xS değişkenine kayıt sayısının iki katı kadar "x" ekleneceğinden bunlarıda
çıkardım. Çıkarmasakta olurdu, çünkü iletiler için kullanılan alan aslında bu
bulduğumuz değerden fazladır.
Bir ileti için,
gönderici, alıcı, tarih, okundu bilgisi ve ileti numarası gibi alanlarda
kullanılıyor. Bunları göz ardı ettim. Eğer gözardı etmek istemesem select
ifadesine bu alanlardan text türünde olanların adlarınıda yazardım. alıcı,
gonderici gibi. Tabii o zaman "x" lerin sayısıda artardı. Son olarak bulduğum
değere her ileti için tarih alanı 4 byte kullandığından (iletisayısı x 4)
eklerdim. Ayrıca ino için integer olduğundan ve 4 byte kullandığından
(iletisayısı x 4) eklerdim. Okundu, asil ve gsil alanları true/false
olduklarından bunları eklemezdim. Tabii bu kadarı işi abartmak olacağından
yapmadım.
Hamiş;
konu ve metin alanları unicode sıkıştırmalıdır. Yani harf başına 1 byte
kullanır. Aksi halde bulunan değeri 2 ile çarpmak gerekir.
İleti
tablosu
| Alan Tipi |
Alan Adı |
| counter |
ino |
| text(50) |
alici |
| text(50) |
gonderici |
| datetime |
zaman |
| bit |
okundu |
| longtext |
konu |
| longtext |
metin |
| bit |
gsil |
| bit |
asil |
ufukyayla 06.03.2005 20:29:07 Yorumlar [0]
Yalnızlık Şarkısı
İnternette başıboş gezen paketler,
Sitemde sizin kadar yalnızım,
Bir blog olsa belki duyulur sesim,
Ben yalnızım, ben yalnızım, yalnızım.
Scriptim bu, böyle yazılmış kodum,
Hiç kimsenin tasarımında yoktur gözüm,
Bir blog kodu yazar ki'bördüm,
Ben yalnızım, ben yalnızım, yalnızım.
Girmediğim site kalmadı dünyada,
Hangi foruma girdimse kaldı izim,
ASP'ye geçer, kendime geçmez sözüm,
Ben yalnızım, ben yalnızım, yalnızım.
ufukyayla 05.03.2005 15:46:11 Yorumlar [1]
Caching Meselesi
Eğer bir yerde göstereceğiniz veri çok yerden derleniyorsa ve bir çok bağlantı açıp-kapatmak zorunda kalıyorsanız bütün bu verileri önceden derleyip bir yerde saklayıp, sonra her istek geldiğinde oradan okuyup yollamak sitenizi hızlandırabilir. Mesela işbu Karalama Defterinin sağ tarafındaki sabit kısmın oluşturulması için Bölümleri, Son Karalamaları, Son Yorumları ve vs. yi listelemek için tam 4 sorulamanın ve bunu yanısıra bir sürü kod satırının çalışması gerekiyor. Her istekte bunu yapmak iyi bir fikir değil. Ben bütün bu listele işlemlerinin sonucusu bir tablodaki bir LongText alanda saklıyorum. Tabii her değişiklikte (Bölüm ekle-sil, Karalama ekle-sil, Yorum ekle-sil vs.) bu alanı güncelliyorum. Karalama Defterini göstermek üzere bir istek gelince bu sağdaki sabit kısmı göstermek için sadece LongText alandaki veriyi yolluyorum. Tabii bu iş için bir tablodaki LongText alanı değilde, bir text dosyasını da kullanabilirdim. Ancak verileri text dosyalarında tutmaktan hoşlanmıyorum. Hem bir bağlantı kurmulmuş ve açıkken neden fazladan FSO nesnesi oluşturayım.
Bu sebeplerden dolayı HTML formatındaki veriyi bir LongText alanda tutmak bana iyi bir fikir gibi görünmüştü ve öyle yapmıştım.
Sonra bu iş için XML kullanmayı düşündüm. Ama sunucuda parsing işi çok zaman alıyor ve yavaş. Yada bu XML dosyasını hiç parsing yapmadan XSL ile gösterilmek üzere istemciye yollayabilirdim. Bu durumda XML dosyasını istemci yorumlamak ve XSL'e göre biçimlendirerek göstermek zorunda kalırdı. Mesele şu ki bütün istemcilerin (browser) XSL dosyalarını yorumlayabileceklerinden veya aynı şekilde yorumlayacaklarından emin değilim. Dahası (aslında 'Doğrusu' demeliydim) XML teknolojisi konusunda bilgi eksikliğim var.
ufukyayla 03.03.2005 10:22:04 Yorumlar [0]
SQL Cümlecikleri
MySQL konusunu epeyce bir araştırdım. Sonuç olarak henüz ASP, VB gibi Microsoft teknolojilerinde kullanılmak üzere hazır olmadığını gördüm. ADO nesne modeline kesinlikle uymuyor. Recordset kullanımı çok sorunlu. Recordset sadece veri okumada kullanılabiliyor, diğer durumlar fiyasko. .Update olmuyor. ANSI SQL'e bile uyumlu değil. Avantaj olarak sadece limit anahtar kelimesinin kullanım biçimi iyi. Bu yüzden MySQL ile vaktimi harcamamaya karar verdim.
Son birkaç aydır sıkça ziyaret ettiğim bir sitede MsSQL kullanmışlar. Anlık ziyaretçi sayıları 10'u geçmediği halde adamların sitesi korkunç yavaş. Aynı site optimize edilse üstelik Access kullanılsa bundan daha hızlı olur. Birçok kişi sorgularda * kullanmaya, her veri için bağlantı açmaya alışkındır. Site yavaşlayınca önce Access'den, sonra bir SQL sunucusuna geçilip SQL sunucusundan şikayet edilir. Anlık ziyaretçi sayısı 10 civarında olan bir sitede Access'in altından kalkamayacağı bir durum oluşmaz. Eğer oluşuyorsa sorun koddadır. Mesele kesinlikle optimizasyon meselesidir. Veri eklemede Recordset (.AddNew) yerine INSERT INTO kullanılması pek fayda sağlamıyor. Zaten siteler genelde ekleme değil okuma yapar. Yani bir kere eklenen veri defalarca okunur. Dar boğaz eklemede değil okumadadır. Bence ekleme için açılan Recordset'i 0 kayıt döndürecek şekilde (where kno=-1 gibi) açmak yeterlidir. Özellikle çoğu programcının INSERT INTO ile VT'ye veri eklerken ziyaretçinin ' " % ? _ * # ; vs. girmiş olabileceğini unutmaları ilginç sorunlara sebep oluyor. UPDATE kullanımında da aynı hatalar yapılıyor. Birçok programcının JOIN kullanmayı bilmediğini, bu yüzden basit bir iş için 2-3 kayıt kümesi açtıklarını ve hatta .Find ile (en kötüsü döngü ile) işi kotarmaya çalıştıklarını incelediğim çoğu örnekte gördüm. Hatta tek sorgu kullansalar bile elde ettikleri veriyi gruplandırmadıklarından işi koda havale etmek kolaycılığına da rastlıyorum. Bu konuda bir otorite değilim, iyi bir programcı da sayılmam, ama burada saydığım hataların hepsini defalarca yapmış biri olarak hatalarla aramdaki ünsiyet gereği "Kimse hataları benim kadar iyi tanıyamaz" diyebilirim. Bu sebeple bu karalamanın yorumlarında bazı SQL sorgu örnekleri vereceğim. Verdiğim örnekler bu sitede (özellikle işbu karalama defterinde) kullanılanlar arasından seçilecek. Umarım yararı olur. Yoruma açık tabii.
ufukyayla 01.03.2005 13:03:00 Yorumlar [13]
Sayfalar : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 [17] 18 19 20 21
|
