|  |  | |  | |  
Site artık aktif değildir. | |  | |  |
| | | | | Powered By Access | Bir çok insan sitesine MySQL, MsSQL logosu koymuştur ama bir kişi bile gariban Access'inkini koymamıştır. Bu kadar emeği geçti, gücenmesin.
Tablolarım Access'te,
Sorgulanır aheste aheste.
Yavaşlar VT, üç-beş üyede,
Ah neyleyim bu hostinge,
Hasret kaldım MSSQL'e.
Ben sana dayanamam MySQL,
Ben sana aldanamam.
Ben sana katlanamam MySQL,
Ben seni kullanamam.
VT'yi flood ağlatır,
Siteyi bağlantı ağlatır,
Ben Access'e neylemişim,
Beni her zaman ağlatır.
Ben sana dayanamam MySQL,
Ben sana aldanamam.
Ben sana katlanamam MySQL,
Ben seni kullanamam. |
09.03.2005 19:21 ufukyayla |
Dokuz yorum var |
| | | | |
| | | | | Murphy Yasaları | Tamamlanma tarihi ile ilgili beklentilerin planlamada kazandığı ciddiyet arttıkça gecikme de büyür.
Kötüden daha kötüye gidecek olaylara yapılan müdahale en kötüye ulaşma hızını arttırır.
İşinizin tüm aşamalarını planlayıp birinci aşama ile işe başladığınızda, birinci aşamadan önce tamamlanmış olması gereken bir aşama daha olduğu ortaya çıkar.
İşinizi ne kadar iyi yaparsanız yapın, mutlaka sağını solunu değiştirmek isteyecek bir amiriniz/müşteriniz bulunacaktır.
Hiçbir şey göründüğü kadar kolay değildir.
Her şey düşündüğünüzden daha fazla zaman alır.
Eğer birkaç şeyin ters gitme olasılığı varsa, en fazla zarar verebilecek olan ters gidecektir.
Her işte ters gidebilecek 4 yol görüyorsanız ve bunları başarı ile atlatırsanız, o zaman beşinci bir ters yolun olduğunu göreceksiniz.
Her şeyi kendi haline bırakırsanız, kötü de en kötüye kayar.
Ne zaman bir şey yapmaya kalksanız, başka bir şeylerin daha önce yapılmış olması gerektiğini görürsünüz.
Her çözüm yeni sorunlar doğurur.
Hiç bir şeyi kazadan beladan uzak tutmak mümkün değildir. Çünkü aptallar çok beceriklidir.
Eğer işlerin ters gittiğinde çok şey kaybedeceksen, onlara çok dikkatli bak.
Gülümse... yarın daha kötü olacaktır.
Eğer bir şeyi, hiç kimsenin yanlış anlayamayacağı kadar açık anlatıyorsan, birileri mutlaka yanlış anlayacaktır.
Herkesin uygun bulacağından emin olduğun bir iş yapıyorsan, birileri mutlaka bundan hoşlanmayacaktır.
İşler tam da ters gitmeyeceği noktaya gildiği zaman ters gitmeye başlar.
Ne zaman işler iyi gidiyor gözükse, mutlaka bir şeyleri gözden kaçırıyorsunuzdur.
İnşaatçılar bilgisayar programcılarının program yazdıkları gibi inşaat yapsalardı çıkıp gelecek ilk ağaçkakan bütün uygarlığı yerle bir ederdi.
Uzman, gittikçe daha az konuda daha çok şey bilen, en sonunda da hiçbir şey konusunda kesinlikle hiçbir şey bilmeyen biri haline gelen kişidir.
Hiçbir şey programın dışına çıkmadan ya da bütçeyi aşmadan bitirilemez.
Hata yapmak insana özgüdür, ama her şeyi tam anlamıyla altüst etmek için bir bilgisayar gerekir.
Bir bilgisayar iki saniyede yirmi insanın yirmi yılda yaptığı kadar yanlış yapar. |
08.03.2005 08:46 ufukyayla |
Dört yorum var |
| | | | |
| | | | | 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? |
07.03.2005 13:14 ufukyayla |
Bir yorum var |
| | | | |
| | | | | 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 | |
06.03.2005 20:29 ufukyayla |
Henüz yorumlanmadı |
| | | | |
| | | | | 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. |
05.03.2005 15:46 ufukyayla |
Bir yorum var |
| | | | |
| | | | | 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 veritabanı bağlantısı varken ve açıkken neden ayrıca bir 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. |
03.03.2005 10:22 ufukyayla |
İki yorum var |
| | | | |
| | | | | 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. |
01.03.2005 13:03 ufukyayla |
On bir yorum var |
| | | | |
| | | | | Ortak Üyelik Sistemi | (Bu proje'in 3 ayağıdan 2 si tamamlandı, yorumları okuyun)
Bir domainde çalışan ortak üyelik sistemi için (OÜS);
Önce katılımcı siteler kavramı oturtulacak, şöyle ki;
Katılımcı her site için bir hesap açılacak, bir şifresi olacak.
Üyeler buraya (OÜS'e) üye olacak. Ve hangi sitelerde üye olarak görünmek istiyorlarsa onları işaretleyecek. (İşaretlediği sitelerden onay alması katılımcı siteye bağlı olacak, ama üyeliği e-maille onaylama gibi birşey elbette olacak.)
Üyeler katılımcı sitelerden birine giriş yapmak isterse o sitede bulunan üye girişi formunu;
Ad:
Şifre:
doldurup girişe basacak. Bu formdan gelen bilgiye;
SiteID
SitePWD
(katılımcı site tarafından) eklenecek ve OÜS'ün giriş doğrulama scriptine yollanacak (login.asp gibi)
Bu (OÜS'deki) script girilen üye adının ve şifresinin doğru olup olmadığını kontrol edecek, gelen SiteID'ye göre bu siteyi seçip seçmediğine bakacak, ve tabii SitePWD doğru ise o site için açılan hesaptan öğreneceği adresteki scripte (katılımcı sitedeki bir scripte) üyenin bütün bilgilerini yollayacak. Üye giriş yapmış olacak.
Bu bilgiler;
nick (üyenin kısa adı)
email (üyenin doğrulanmış e-mail adresi)
web (üyenin web adresi)
avatar (üyenin seçtiği avatarın url'si "http://www.ous.net/avatar/123.gif" gibi.)
otarih (üyenin bir önceki giriş anı "dd/mm/yyy hh:mm:ss")
gtarih (şimdiki giriş anı "dd/mm/yyy hh:mm:ss")
vs. vs.
Ayrıca OÜS de bir çok sorgulama olacak;
VerUyeAdı(nick)
Parametre üyenin niki
Dönen değer Üyenin gerçek adı
VerUyeEmail(nick)
Parametre üyenin niki
Dönen değer Üyenin e-mail adresi.
VerUyeAvatar(nick)
Parametre üyenin niki
Dönen değer Üyenin avatarının url'si "http://www.ous.net/avatar/123.gif" gibi.
(Bu sorgulamaları yapan katılımcı site sorgulama için SiteID ve SitePwd yolayacak.)
Henüz üye seviyelendirme ve üyelerin yetkilendirilmesi konularını düşünmedim. Bunlar katılımcı siteye bırakılabilir.
İlk aklıma gelenler bunlar, çok saçma gibi duruyor ama sizce bu tutar mı?
Sırf kendimi geliştirmek adına bile yapabilirim. Azda XML kastırmış olurum.
Devamı yorumlarda... |
20.02.2005 13:55 ufukyayla |
On dört yorum var |
| | | | |
| | | | | ASP Macerası Nasıl başladı | | 2 veya 3 yıl önceydi. Konyadan Nevşehire gidiyordum, sevgili dostum Alposman ile beraberdim yola çıkmadan önce. (Not; Alp'e html'yi ben öğrettim, boynuz kulağı geçti; Alp aldın mı cevabını) Yolda okurum çerez niyetine diye ondan bir kitap aldım "ASP Nedir" gibi bi ismi vardı. Otobüse bindim. Ağırdan okumaya başladım. Başlarda bişi olmadı, ama konular ilerleyince, kendi kendime "Lan ben bunu biliyorum, ASP dedikleri VB'nin ufak biladeri" dedim. Ve 3 saat sonra otobüsten indiğimde asp biliyordum. O ana kadar ASP bildiği mi bilmiyormuşum. |
18.02.2005 11:43 ufukyayla |
Dört yorum var |
| | | | |
|
Üst
Kaplama
