Tüm Platformlar için Hızlı Uygulama Geliştirme Kitabı... Delphi
Ön Sipariş Talebinde Bulunan Üyelerimiz
Sipariş Talebinde Bulunan Üyelerimiz

Konuyu Paylaş : facebook gplus twitter

Konuyu Oyla:
  • Derecelendirme: 0/5 - 0 oy
  • 1
  • 2
  • 3
  • 4
  • 5
Kişisel Site & Bloglar
#31
(14-10-2018, Saat: 23:38)Abdullah ILGAZ Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Giriş yap veya Üye OlYenilenen arayüzü ile sayfamı yayınladım. Henüz kanarya sürüm olduğu için çıkabilecek aksaklıklar olacaktır. Geri-dönüşleriniz önemlidir.

Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol

Tema güzel içerik oluştukça daha da güzelleşecek gibi görünüyor ama ilk açılışta sayfa yüklenmesi çok uzun sürdü
Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol
Kuvvete dayanamayan adalet aciz, 
Adalete dayanamayan kuvvet zalimdir.
WWW
Cevapla
#32
(14-10-2018, Saat: 23:38)Abdullah ILGAZ Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Giriş yap veya Üye OlYenilenen arayüzü ile sayfamı yayınladım. Henüz kanarya sürüm olduğu için çıkabilecek aksaklıklar olacaktır. Geri-dönüşleriniz önemlidir.

Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol

Hayırlı uğurlu olsun kardeşim @Abdullah ILGAZ
Mal sahibi, mülk sahibi
Hani bunun ilk sahibi ?
Mal da yalan mülk de yalan
Var biraz da sen oyalan...
WWW
Cevapla
#33
(15-10-2018, Saat: 08:31)yhackup Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Giriş yap veya Üye OlTema güzel içerik oluştukça daha da güzelleşecek gibi görünüyor ama ilk açılışta sayfa yüklenmesi çok uzun sürdü

@yhackup  Veritabanı olmadığı için her talep gidip sunucudaki dosyaları okuyup geliyor. Optimizasyon çalışmasını ilerleyen günlerde yapacağım inşaAllah. Teşekkür ederim, sağolun.
Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol
Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol
Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol
Cevapla
#34
(15-10-2018, Saat: 08:46)Tuğrul HELVACI Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Giriş yap veya Üye OlHayırlı uğurlu olsun kardeşim @Abdullah ILGAZ

@Tuğrul HELVACI Teşekkür ederim abi, inşaAllah sizin sayfa kadar ilgi gören bir blog haline dönüştürebilirim Blush
Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol
Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol
Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol
Cevapla
#35
@Abdullah ILGAZ amaç metni çok hoş olmuş. c#'da not found hatası ise microsoft'un mavi ekran çağrışımı yaptı Smile) Umarım faydası olur ve güzel bir çalışmaya imza atmış olursunuz.
Topluluk mopluluk yok :/
Cevapla
#36
(14-10-2018, Saat: 23:38)Abdullah ILGAZ Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Giriş yap veya Üye OlYenilenen arayüzü ile sayfamı yayınladım. Henüz kanarya sürüm olduğu için çıkabilecek aksaklıklar olacaktır. Geri-dönüşleriniz önemlidir.

Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol

Eline sağlık en kısa zamanda şahin sürümü de bekliyoruz kardeşim :-)
WWW
Cevapla
#37
(15-10-2018, Saat: 11:50)boreas Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol@Abdullah ILGAZ  amaç metni çok hoş olmuş. c#'da not found  hatası ise microsoft'un mavi ekran çağrışımı yaptı Smile) Umarım faydası olur ve güzel bir çalışmaya imza atmış olursunuz.

Teşekkür ederim @boreas   Wink  Yakında C# makalelerini de ekleyeceğim, o zaman 404 almazsınız Smile)
Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol
Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol
Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol
Cevapla
#38
(15-10-2018, Saat: 00:32)3ddark Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol
(23-07-2018, Saat: 09:15)Tuğrul HELVACI Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Giriş yap veya Üye OlYazmayı düşünüyorum, lâkin ilk olarak siteye giriş şifremi hatırlamıyorum, şifrem diğer bilgisayarımda. Ve bir de kişisel bazı ciddi meşgalelerim var, onlar nihayetlenince kafam rahata erebilir. Sonrası ise Allah kerim. Low level programlamaya ilgisi olan pek kimse yok ama, ben yinede bilgim ve zamanım elverdiği ölçüde paylaşımlar yapmayı düşünüyorum tabii.

@Tuğrul HELVACI hocam vaktiniz olması durumunda burada veya blogunuzda SQL tarafından Transaction nasıl yapılmalı nasıl yönetilmeli. Transaction Isolation Level nedir. Transaction Isolation Level seviyeleri hangi durumlarda hangi seçenek kullanılmalıdır. Transaction, Lock timeOut süreleri nedir ve ne işe yarar. Bunlar benim aklıma gelenler bunların haricinde yazmadığım veya bilmediğim konular varsa tabi bilginiz tecrübeniz dahilinde bir makale çok iyi olurdu.

Ben Transaction ları aktif olarak kullanıyorum fakat tam anlamıyla hakim olduğuma inanmıyorum. Gördüğüm kadarı ile buradaki arkadaşların çoğu da bu Transaction olayını pek kullanmıyor gibi (naçizane kendi görüşüm ve tespitim). Mesela kendi yaptığım çok kullanıcılı ve yoğun kullanılan uygulama bazen Lock lar ile kullanıcıların birbirlerini kilitlemesine sebep olabiliyor. Böyle durumlar yazılım tarafında veya SQL (MsSQL, PostgreSQL, mySQL fark etmez) Server tarafından nasıl çözümlenir veya hangi işlemler ile bu sorunların üstesinden gelinir.

Bunlar hakkında ayrıntılı bir makaleniz olursa çok sevinirim. Sadece SELECT INSERT UPDATE DELETE işlemleri ile uğraşan arkadaşların SQL tarafının derinlerinde nelerin olduğu programcıya nasıl yardımcı olduğunu bilmeleri adına çok iyi olacaktır.

Burada bununla ilgili makale yazacak arkadaşlar varsa (@Fesih ARSLAN yönetime duyurulur Blush ) tabi ki onlarında tecrübelerini ve bilgilerini dinlemek isteriz.

Tekrar üzerine bastırarak söylüyorum. Tabi ki makale işi kısa bir iş değil epey zaman alıyor. Bunun için VAKTİ OLAN ARKADAŞLAR varsa. Bu konu ile ilgili olarak forumda çok fazla bilgi yok neredeyse hiç yok denecek seviyede. Makale tadında olursa süper olur.

Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol linkte verdiğimi gibi bir sürü örnek kullanım mevcut fakat. Kullanıcıların edinmiş olduğu deneyimler çok daha fazla değerli oluyor.

Aslında Transaction'ları anlamak; multi threading'i ve senkronizasyon mekanizmalarını anlamak ile çok yakından bağlantılı. Anahtar kelime PAYLAŞILAN KAYNAKLAR ve bu kaynaklara ERİŞECEK NESNE SAYISI. Bütün düğüm burada başlayıp, burada karmaşıklaşıyor.

 Paylaşılan kaynak ne olursa olsun, sınırsız kaynaklara sahip olmadığımız için paylaşılan kaynağa erişimlerin mecburen senkronize edilmeleleri gerekiyor. Uygulama geliştirme dünyasında bunların spesifik adları Critical Section, Mutex, Semaphore, Event, Waitable Timer ... vb olabilirken, RDBMS (İlişkisel Veritabanı Yönetim Sistemi)'lerde Transaction ve Locking oluveriyor ;-)

 Aslında olayın derinliklerinde, mevcut bir kaynağa erişimi organize etmeye çalışan bir veritabanı yönetim sistemi uygulaması var. Bazı kaynaklara bazı durumlarda birden fazla erişimin olmasına izin verirken (semaphore olabilir mesela), bazen de kaynağı sahiplenip kimsenin erişmemesini sağlıyor(Bir çok senkronizasyon nesnesi kullanılıyor olabilir. 1 adetlik semaphor, session bazlı mutex, event vb).

 Burada; "Sınırlı sayıda kaynağa sınırsız sayıda erişimi nasıl organize ederiz ?" sorusuna yanıt aramak ve üstünde düşünmek gerekiyor. Bakış açısı bu şekilde olduğunda bir çok sorun kendiliğinden anlaşılmış oluyor.

 Örneğin, bir tuval düşünelim. Bu tuval üzerinde 4 ayrı ressam aynı anda birbirlerini rahatsız etmeden ve hiç bir şeye engel olmadan birlikte çalışabilirler. (Her bir ressam tuvalin 4 ayrı köşesinde çalışıyor). Ancak 5nci bir ressam gelse ve sol üst köşede çalışmak istese ne olacak ?

 Orada çalışan bir ressam zaten var. O ressam sol üst köşede çalışır bir objeyi çizer iken, diğer ressam çizileni silse ne olurdu ?

 Ya da; benzer bir şekilde; bir tablo (veritabanı tablosu) üzerinde 1453 ID'li bir kayda konumlanan ve A alanının değerini "İstanbul'un Fethi" yapmak isteyen; aynı zaman diliminde aynı kayda konumlanıp, A alanının değerini bir başka değer yapmaya çalışan nesneyi nasıl engellerdiniz ? Ya da bu işi nasıl senkronize ederdiniz.

Yani "biriniz şu işi yapın, sen bekle bu arada, ardından sen gel" diyen bir algoritmaya ihtiyacınız olur. İşletim sistemi tamamen bu kural üzerine bina edilmiştir. Aynı anda bir kaynağı sadece bir tek nesne kullanıyordur. Aynı kaynağı kullanan çok fazla nesne sadece sanal olarak bizlere sunulmuştur. Gerçek bu şekilde değildir. Tıpkı saniyede 25 frame ekran görüntüsü olduğu ama gözümüzün bunu farkedemediği gibi.

 Velhasıl, herşeyden önce thread'ler , ortak paylaşılan nesneler(CPU, Ram, Disk...) bu fiziksel cihazların sınırlı sayıda olduğu, ancak erişmek isteyenlerin sınırsız sayıda olduğu gibi düşünceler ile haşır neşir olunur ise; o zaman işleyişin nasıl olduğu daha rahat anlaşılabilir.

 RDBMS için lock; aynı anda sadece belirli sayıda isteğin erişimini kontrol etmekten başka bir şey değildir. Exclusive Lock olduğunda sadece bir istek, shared lock olunca da birden fazla istek aynı anda aynı kaynağa erişir ve kullanabilir.

 Isolasyon seviyeleri, veritabanlarının paylaşımlı kaynaklara erişiminin algoritmalarıdır. Tabii, bu algoritmalar sizin tasarımlarınızdan da etkilenir. Unique index'ler, alan türleri, NULL olup olamauyacakları vb.

 Ben bir DBA değilim, son derece derin biliyorum der isem hatalı bir ifade olur. Lâkin büyük bir veritabanı uygulaması yapacak kadar SQL Server'a has tabirleri ve terimleri biliyorum.

 Kuvvetle muhtemeldir ki, aramızda işi DBA olan birileri çok daha derin ve detaylı anlatabilecektir.
Mal sahibi, mülk sahibi
Hani bunun ilk sahibi ?
Mal da yalan mülk de yalan
Var biraz da sen oyalan...
WWW
Cevapla
#39
(15-10-2018, Saat: 17:27)Tuğrul HELVACI Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol
(15-10-2018, Saat: 00:32)3ddark Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol@Tuğrul HELVACI hocam vaktiniz olması durumunda burada veya blogunuzda SQL tarafından Transaction nasıl yapılmalı nasıl yönetilmeli. Transaction Isolation Level nedir. Transaction Isolation Level seviyeleri hangi durumlarda hangi seçenek kullanılmalıdır. Transaction, Lock timeOut süreleri nedir ve ne işe yarar. Bunlar benim aklıma gelenler bunların haricinde yazmadığım veya bilmediğim konular varsa tabi bilginiz tecrübeniz dahilinde bir makale çok iyi olurdu.

Ben Transaction ları aktif olarak kullanıyorum fakat tam anlamıyla hakim olduğuma inanmıyorum. Gördüğüm kadarı ile buradaki arkadaşların çoğu da bu Transaction olayını pek kullanmıyor gibi (naçizane kendi görüşüm ve tespitim). Mesela kendi yaptığım çok kullanıcılı ve yoğun kullanılan uygulama bazen Lock lar ile kullanıcıların birbirlerini kilitlemesine sebep olabiliyor. Böyle durumlar yazılım tarafında veya SQL (MsSQL, PostgreSQL, mySQL fark etmez) Server tarafından nasıl çözümlenir veya hangi işlemler ile bu sorunların üstesinden gelinir.

Bunlar hakkında ayrıntılı bir makaleniz olursa çok sevinirim. Sadece SELECT INSERT UPDATE DELETE işlemleri ile uğraşan arkadaşların SQL tarafının derinlerinde nelerin olduğu programcıya nasıl yardımcı olduğunu bilmeleri adına çok iyi olacaktır.

Burada bununla ilgili makale yazacak arkadaşlar varsa (@Fesih ARSLAN yönetime duyurulur Blush ) tabi ki onlarında tecrübelerini ve bilgilerini dinlemek isteriz.

Tekrar üzerine bastırarak söylüyorum. Tabi ki makale işi kısa bir iş değil epey zaman alıyor. Bunun için VAKTİ OLAN ARKADAŞLAR varsa. Bu konu ile ilgili olarak forumda çok fazla bilgi yok neredeyse hiç yok denecek seviyede. Makale tadında olursa süper olur.

Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol linkte verdiğimi gibi bir sürü örnek kullanım mevcut fakat. Kullanıcıların edinmiş olduğu deneyimler çok daha fazla değerli oluyor.

Aslında Transaction'ları anlamak; multi threading'i ve senkronizasyon mekanizmalarını anlamak ile çok yakından bağlantılı. Anahtar kelime PAYLAŞILAN KAYNAKLAR ve bu kaynaklara ERİŞECEK NESNE SAYISI. Bütün düğüm burada başlayıp, burada karmaşıklaşıyor.

 Paylaşılan kaynak ne olursa olsun, sınırsız kaynaklara sahip olmadığımız için paylaşılan kaynağa erişimlerin mecburen senkronize edilmeleleri gerekiyor. Uygulama geliştirme dünyasında bunların spesifik adları Critical Section, Mutex, Semaphore, Event, Waitable Timer ... vb olabilirken, RDBMS (İlişkisel Veritabanı Yönetim Sistemi)'lerde Transaction ve Locking oluveriyor ;-)

 Aslında olayın derinliklerinde, mevcut bir kaynağa erişimi organize etmeye çalışan bir veritabanı yönetim sistemi uygulaması var. Bazı kaynaklara bazı durumlarda birden fazla erişimin olmasına izin verirken (semaphore olabilir mesela), bazen de kaynağı sahiplenip kimsenin erişmemesini sağlıyor(Bir çok senkronizasyon nesnesi kullanılıyor olabilir. 1 adetlik semaphor, session bazlı mutex, event vb).

 Burada; "Sınırlı sayıda kaynağa sınırsız sayıda erişimi nasıl organize ederiz ?" sorusuna yanıt aramak ve üstünde düşünmek gerekiyor. Bakış açısı bu şekilde olduğunda bir çok sorun kendiliğinden anlaşılmış oluyor.

 Örneğin, bir tuval düşünelim. Bu tuval üzerinde 4 ayrı ressam aynı anda birbirlerini rahatsız etmeden ve hiç bir şeye engel olmadan birlikte çalışabilirler. (Her bir ressam tuvalin 4 ayrı köşesinde çalışıyor). Ancak 5nci bir ressam gelse ve sol üst köşede çalışmak istese ne olacak ?

 Orada çalışan bir ressam zaten var. O ressam sol üst köşede çalışır bir objeyi çizer iken, diğer ressam çizileni silse ne olurdu ?

 Ya da; benzer bir şekilde; bir tablo (veritabanı tablosu) üzerinde 1453 ID'li bir kayda konumlanan ve A alanının değerini "İstanbul'un Fethi" yapmak isteyen; aynı zaman diliminde aynı kayda konumlanıp, A alanının değerini bir başka değer yapmaya çalışan nesneyi nasıl engellerdiniz ? Ya da bu işi nasıl senkronize ederdiniz.

Yani "biriniz şu işi yapın, sen bekle bu arada, ardından sen gel" diyen bir algoritmaya ihtiyacınız olur. İşletim sistemi tamamen bu kural üzerine bina edilmiştir. Aynı anda bir kaynağı sadece bir tek nesne kullanıyordur. Aynı kaynağı kullanan çok fazla nesne sadece sanal olarak bizlere sunulmuştur. Gerçek bu şekilde değildir. Tıpkı saniyede 25 frame ekran görüntüsü olduğu ama gözümüzün bunu farkedemediği gibi.

 Velhasıl, herşeyden önce thread'ler , ortak paylaşılan nesneler(CPU, Ram, Disk...) bu fiziksel cihazların sınırlı sayıda olduğu, ancak erişmek isteyenlerin sınırsız sayıda olduğu gibi düşünceler ile haşır neşir olunur ise; o zaman işleyişin nasıl olduğu daha rahat anlaşılabilir.

 RDBMS için lock; aynı anda sadece belirli sayıda isteğin erişimini kontrol etmekten başka bir şey değildir. Exclusive Lock olduğunda sadece bir istek, shared lock olunca da birden fazla istek aynı anda aynı kaynağa erişir ve kullanabilir.

 Isolasyon seviyeleri, veritabanlarının paylaşımlı kaynaklara erişiminin algoritmalarıdır. Tabii, bu algoritmalar sizin tasarımlarınızdan da etkilenir. Unique index'ler, alan türleri, NULL olup olamauyacakları vb.

 Ben bir DBA değilim, son derece derin biliyorum der isem hatalı bir ifade olur. Lâkin büyük bir veritabanı uygulaması yapacak kadar SQL Server'a has tabirleri ve terimleri biliyorum.

 Kuvvetle muhtemeldir ki, aramızda işi DBA olan birileri çok daha derin ve detaylı anlatabilecektir.

@Tuğrul HELVACI  bey teşekkürler.
PostgreSQL - Linux - Delphi, Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol
WWW
Cevapla
#40
(15-10-2018, Saat: 22:04)3ddark Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Giriş yap veya Üye Ol
(15-10-2018, Saat: 17:27)Tuğrul HELVACI Adlı Kullanıcıdan Alıntı: Linkleri Görebilmeniz İçin Giriş yap veya Üye OlAslında Transaction'ları anlamak; multi threading'i ve senkronizasyon mekanizmalarını anlamak ile çok yakından bağlantılı. Anahtar kelime PAYLAŞILAN KAYNAKLAR ve bu kaynaklara ERİŞECEK NESNE SAYISI. Bütün düğüm burada başlayıp, burada karmaşıklaşıyor.

 Paylaşılan kaynak ne olursa olsun, sınırsız kaynaklara sahip olmadığımız için paylaşılan kaynağa erişimlerin mecburen senkronize edilmeleleri gerekiyor. Uygulama geliştirme dünyasında bunların spesifik adları Critical Section, Mutex, Semaphore, Event, Waitable Timer ... vb olabilirken, RDBMS (İlişkisel Veritabanı Yönetim Sistemi)'lerde Transaction ve Locking oluveriyor ;-)

 Aslında olayın derinliklerinde, mevcut bir kaynağa erişimi organize etmeye çalışan bir veritabanı yönetim sistemi uygulaması var. Bazı kaynaklara bazı durumlarda birden fazla erişimin olmasına izin verirken (semaphore olabilir mesela), bazen de kaynağı sahiplenip kimsenin erişmemesini sağlıyor(Bir çok senkronizasyon nesnesi kullanılıyor olabilir. 1 adetlik semaphor, session bazlı mutex, event vb).

 Burada; "Sınırlı sayıda kaynağa sınırsız sayıda erişimi nasıl organize ederiz ?" sorusuna yanıt aramak ve üstünde düşünmek gerekiyor. Bakış açısı bu şekilde olduğunda bir çok sorun kendiliğinden anlaşılmış oluyor.

 Örneğin, bir tuval düşünelim. Bu tuval üzerinde 4 ayrı ressam aynı anda birbirlerini rahatsız etmeden ve hiç bir şeye engel olmadan birlikte çalışabilirler. (Her bir ressam tuvalin 4 ayrı köşesinde çalışıyor). Ancak 5nci bir ressam gelse ve sol üst köşede çalışmak istese ne olacak ?

 Orada çalışan bir ressam zaten var. O ressam sol üst köşede çalışır bir objeyi çizer iken, diğer ressam çizileni silse ne olurdu ?

 Ya da; benzer bir şekilde; bir tablo (veritabanı tablosu) üzerinde 1453 ID'li bir kayda konumlanan ve A alanının değerini "İstanbul'un Fethi" yapmak isteyen; aynı zaman diliminde aynı kayda konumlanıp, A alanının değerini bir başka değer yapmaya çalışan nesneyi nasıl engellerdiniz ? Ya da bu işi nasıl senkronize ederdiniz.

Yani "biriniz şu işi yapın, sen bekle bu arada, ardından sen gel" diyen bir algoritmaya ihtiyacınız olur. İşletim sistemi tamamen bu kural üzerine bina edilmiştir. Aynı anda bir kaynağı sadece bir tek nesne kullanıyordur. Aynı kaynağı kullanan çok fazla nesne sadece sanal olarak bizlere sunulmuştur. Gerçek bu şekilde değildir. Tıpkı saniyede 25 frame ekran görüntüsü olduğu ama gözümüzün bunu farkedemediği gibi.

 Velhasıl, herşeyden önce thread'ler , ortak paylaşılan nesneler(CPU, Ram, Disk...) bu fiziksel cihazların sınırlı sayıda olduğu, ancak erişmek isteyenlerin sınırsız sayıda olduğu gibi düşünceler ile haşır neşir olunur ise; o zaman işleyişin nasıl olduğu daha rahat anlaşılabilir.

 RDBMS için lock; aynı anda sadece belirli sayıda isteğin erişimini kontrol etmekten başka bir şey değildir. Exclusive Lock olduğunda sadece bir istek, shared lock olunca da birden fazla istek aynı anda aynı kaynağa erişir ve kullanabilir.

 Isolasyon seviyeleri, veritabanlarının paylaşımlı kaynaklara erişiminin algoritmalarıdır. Tabii, bu algoritmalar sizin tasarımlarınızdan da etkilenir. Unique index'ler, alan türleri, NULL olup olamauyacakları vb.

 Ben bir DBA değilim, son derece derin biliyorum der isem hatalı bir ifade olur. Lâkin büyük bir veritabanı uygulaması yapacak kadar SQL Server'a has tabirleri ve terimleri biliyorum.

 Kuvvetle muhtemeldir ki, aramızda işi DBA olan birileri çok daha derin ve detaylı anlatabilecektir.

@Tuğrul HELVACI  bey teşekkürler.

Rica ederim. Faydalı olabildi isem ne âla. Shy
Mal sahibi, mülk sahibi
Hani bunun ilk sahibi ?
Mal da yalan mülk de yalan
Var biraz da sen oyalan...
WWW
Cevapla

Konuyu Paylaş : facebook gplus twitter



Konu ile Alakalı Benzer Konular
Konular Yazar Yorumlar Okunma Son Yorum
Lightbulb Web site tasarım programı AliZairov 5 949 01-02-2017, Saat: 22:47
Son Yorum: engerex



Konuyu Okuyanlar: 1 Ziyaretçi