Saturday, November 6, 2010

Otomasyon ve Kaynak Yönetimi Sistemleri Etkileşimleri

Özet: İş süreçlerinin ve üretim süreçlerinin otomasyonu, maliyetlerin kontrolu ve kayıpların azaltılması için kaçınılmazdır. Bakım faaliyetlerinin otomasyon sistemleri ile etkileşimi, kayıpların azaltılması konusunda önemli fırsatlar sunmaktadır. Bu çalışmada bakım yönetim teknikleri ve bakım yönetim tekniklerinin otomasyon sistemleri ile etkileşimi irdelenmektedir.



Giriş:

Plansız duruşların dünya ekonomilerine yarattığı maliyet tüm dünyada 2.000.000.000.000$ (iki trilyon USD) üzerindedir ve sadece Amerika Birleşik Devletlerinde bu kayıpların yaklaşık 740.000.000.000$ (yediyüzkırkmilyar USD) civarında olduğu tahmin edilmektedir [1]

Plansız duruşlar firma içerisinde her bölümü farklı şekillerde etkiler. Örneğin, satış ve lojistik birimleri için geç teslimat, satın alma ve muhasebe birimleri için tedarik ve maliyetlerinde farklılaşma, üretim birimleri için kalite ve yeniden üretim, işletme birimlerini için yeniden ölçme ihtiyacı ve ayar kayıpları, insan kaynakları birimlerini çalışanların iş saatlerinde değişim sorunu olarak kendisini gösterebilir.

Bakım yönetiminin entegre üretim sisteminin bir parçası olmaması plansız duruşların engellenmesi ve etkilerinin maliyetlendirilmesini konusunda yaşanılan en büyük güçlüklerdendir.

 
Otomasyon ve Kaynak Yönetimi Sistemleri Etkileşimleri: Bilişim sistemlerindeki gelişmeler bakım yönetimini de etkilemektedir. Bu etki bakım yönetiminin otomasyon ve kaynak yönetim sistemlerine entegrasyonunu hızlandırıcı yöndedir.





Şekil 1. Üretim Tesislerindeki otomasyon ve kaynak yönetim sistemleri etkileşimleri.



Bakım Yönetimi Yetersizliğinin, Yönetim Teknikleri Üzerindeki Bozucu Etkisi: 1990 yılında Harvard Bussines Review dergisinde yayınladığı bir yazı ile ilk defa “değişim mühendisliği” kavramını ortaya atarak tüm dünyada yönetim teknikleri üzerinde çok büyük etki yaratmış olan Michael Hammer, 1993 yılında James Champy ile birlikte yazdığı “Şirketlerde Değişim Mühendisliği” isimli kitabında şirket yöneticilerinin en büyük sorunu aşağıdaki şekilde tanımlamıştır:



“Şirket yöneticilerinin çoğuna en büyük sorunları yaşatan süreç sözcüğüdür. İşadamlarının çoğu “süreç-odaklı” olmayı beceremez; bunlar görev, iş, insan, yapı gibi kavramlar üzerinde yoğunlaşırlar, ama asla süreç üzerinde değil. İş sürecini, bir veya bir kaç çeşit girdinin alındığı, bunlardan, müşteri için değer oluşturacak bir çıktının yaratıldığı faaliyetlerin toplamı olarak tanımlıyoruz” [2,5]



Beklenmedik sorunlar açısından bakıldığında, bakım yönetimindeki yetersizlikler, şirket yöneticilerine en acı sürprizleri yaşatabilme potansiyeline sahiptir. Tablo 1’de farklı yönetim tekniklerinin, yetersiz bakım yönetimi ile nihai amaçlarına erişimi nasıl engelleyeceği özetlenmiştir.











Otomasyon Sistemleri ve İletişim Ağı Seviyeleri: İletişim ve bilgi sistemlerindeki gelişmeler bakım yönetim tekniklerini de etkilemektedir. Bu etkileşim kendisini bakım yönetiminin de “Entegre Üretim Sistemi” ağının bir parçası olarak göstermektedir. Klasik entegre üretim sistem ağı ve bu ağa ait katmanlar Şekil 2’de özetlenmiştir [3]







Şekil 2: Entegre Üretim Sistemi entegrasyon katmanları



Klasik üretim sistemi entegrasyon katmanlarının oluşumu dikkat edileceği gibi süreç odaklı bir yaklaşımdan ziyade teknik alt yapıya bağlı olarak oluşmuştur. Bunu katmanlar arasındaki iletişim ağlarının yapısında daha net olarak görmek mümkündür. (Şekil 3) [3]







Şekil 3: Entegre Üretim Sistemi işletme ağları



Süreç odaklı olmayan teknik alt yapı, üretim makinaları ile iş ve kaynak yönetim sistemleri arasındaki iletişimi kolaylaştırırken, çoğu uygulamada bakımı bu iletişim ağının dışında tutmak zorunda kalmıştır. Bu durum kendisini ironi ile karışık “I operate, you fix it syndrome” (ben çalıştırırım, sen onarırsın sendromu) gibi [4] firma içerisindeki işletme ve bakım grupları arasındaki kopukluk şeklinde göstermiştir. Bunun bir başka yansıması pek çok büyük organizasyon içerisinde kullandığı cihazlar arasında iletişim olmayan insanlar arasında da iletişim olmaması şeklinde ortaya çıkmıştır.

Klasik iletişim alt yapısına bağlı olarak gelişen sıkıntılar varlık yönetim sistemlerinin ortaya çıkması ile aşılmaya başlamıştır. Bakım yönetimi varlık yönetim sistemlerinin önemli bir parçası haline gelmiştir. (Şekil 1 aşağıda tekrar verilmiştir.)









Şekil 1. Üretim Tesislerindeki otomasyon ve kaynak yönetim sistemleri etkileşimleri.



Bakım yönetiminin, entegre üretim sisteminin bir parçası olmasının önünde bulunan iki bariyerden birincisi haberleşme sistemlerindeki gelişmelere bağlı olarak aşılabilmektedir. Örneğin OPC-Server yazılımı aracılığı ile her iletişim ağı katmanı arasında haberleşmeyi imkanı mümkün hale gelmiştir. Bu sayede Seviye 0 ağında bulunan bir sensörden alınan bilgi Seviye 1 ve Seviye 2 ağlarında farklı algılama bilgisi olarak ama Seviye 4 ağında örneğin bir bakım bilgisi olarak kullanılabilmektedir.



Bakım yönetiminin otomasyon sistemleri ile etkileşiminde ikinci ve belki de en önemli engeli Durum Bazlı İzleme sistemleri (CBM – Condition Based Maintenance) ortadan kaldırmaktadır.



Varlık yönetim sistemlerinin entegrasyonunda yaşanılan en büyük sıkıntılardan bir tanesi bakım ile ilgili verilerin bakım teknisyenleri tarafından manual olarak girilmesi zorunluluğunun olmasıdır. Bu durum firmanın mevcut bakım kültürünün değişmesine ve bakım personelinin yapması gereken işlerle ilgili pek çok veri girmek için ilave iş yükü almasına ve manual veri girişleri nedeni ile oluşabilecek veri kaybı ve hatalara neden olmaktadır.



On-line CBM sistemlerinin ana faydası kritik ekipmanların belli zamanlarda veya arıza durumunda izlenmesinin yaratacağı problemleri ortadan kaldırmasıdır. Sürekli izlenen sistemlerde oluşan hata ve arızalar anında görülebilmekte ve otomatik olarak tutulan kayıtlar sayesinde yaşanan sorunlara ait kök-neden analizi kolayca yapılabilmektedir.



Varlık yönetim sistemlerine entegrasyon açısından sağlayacağı fayda ise tıpkı proses kontrol sistemleri ile varlık yönetim sistemleri arasında olduğu gibi istenilen verilerin otomatik olarak aktarılmasıdır.



Örneğin bir motora ait veriler Artesis MCM (Motor Condition Monitoring) sistemi ile izlendiğinde;



1. Bu motora ilişkin pek çok parametre sürekli izlenebilir,

2. Mevcut ve gelişen arızaların analizi arızayı oluşturan sebepleri de irdeleyerek gerçekleştirilir.

3. Bakım planlaması için gerekli olan ne kadar zaman içerisinde bakım yapılmalıdır verisi oluşturulur.

4. Bakım sonrası, yapılan bakımın amacına ulaşıp ulaşmadığı kolayca izlenebilir. [6]



Sadece motorlara ait oluşacak arızaların aylar öncesinden tespiti ile dahi beklenmedik duruşlar engellenebilir ve verimsiz çalışan makinalar tespit edilerek bir sanayi tesisinde yüzbinlerce dolar tasarruf sağlanabilir.



MCM sistemi ile elektrik motorlarının üzerine bir sensör takmadan, sadece motora giden besleme hattı üzerinden akım ve gerilim bilgisini kullanarak motora ait mevcut ve gelişmekte olan arızaları aylar öncesinden tespit eder.



MCM sistemi motorlara ait arıza analiz işlevlerinin yanı sıra üç ana fonksiyonu yerine getirir:



1. İzleme: Motorun üç fazına ait akım, gerilim bilgisi, aktif güç (KW), reaktif güç (kVAr) , güç faktörü, gerilim dengesizliği (%), akım dengesizliği (%), frekans (Hz), Toplam Harmonik (%), 3-5-7-9-11-13. Harmonikler (%) sürekli olarak izlenir ve kaydedilir.[6]



2.Hata Analizi ve Teşhisi: Motorda mevcut ve gelişmekte olan Gevşek zemin/komponent,Balanssızlık/eksenelkaçıklık/Kaplin/rulman,Kayış/aktarma elemanı/sürülen ekipman, Rulman, Rotor, Stator/kısa devre, Dahili elektriksel arızalar, Harici elektriksel arızalar, Şebeke durumu ve Yük Durumu arızalarını, arızanın seviyesine ve ne kadar zaman içerisinde bakım yapılması gerektiği bilgisi ile verir.[6]



3. Bakım Planlama: Mevcut ve gelişmekte olan arızaları yeri ve şiddeti ile birlikte ne kadar zaman içerisinde bakım yapılması bilgisi ile birlikte verir. Yapılan bakım sonrasında arızanın giderilip giderilemediği takip edilebilir.[6]



Kullanılacak bir OPC Server yazılımı aracılığı ile yukarıda yer alan veriler farklı otomasyon ve kaynak yönetim sistemlerinde farklı şekillerde kullanılabilir. Örneğin DCSve SCADA motora ait izlenen veriler işletme yönetimi tarafından izlenirken, hata analizi ve teşhis verileri varlık yönetim sistemlerinde arıza ve kök-neden analizi amacı ile kullanılabilir, bakım planlama verileri ERP sistemlerinde bakım yönetimi verisi olarak kullanılabilir.



Sonuç: Maliyetlerin kontrolü ve tasarruf imkanlarının hayata geçirilebilmesi için bakım yönetiminin entegre üretim sisteminin dahili bir parçası olması kaçınılmazdır. Bakım yönetiminde yaşanacak yetersizliklerin engellenmesi firma yönetim ağları içerisine entegre olmuş bir bakım yönetimi ile mümkündür. CBM sistemlerindeki ve iletişim sistemlerindeki gelişmeler bakım yönetiminin, entegre üretim sistemine entegrasyonu sürecindeki bariyerleri ortadan kaldırmaktadır.



Referanslar:



[1] Orbit Magazine (Vol.26 No.2 2006), Enterprise Reliability: Changing the Game, Robert DiStefano, Chairman and CEO Management Resouces Group Inc. distefanor@mrginc.net, Larry Covino, GE Energy Product Line Leader Reliability Consulting and Implementation Serviceslawrance.covino@ge.com



[2] Reengineering the Coorporation (Şirketlerde Değişim Mühendisliği), Michael Hammer, James Champy,(s.31-32)



[3] The Big Picture-Integrated Manufacturing Systems, Dennis Brandl, BR&L Consulting, The Organisation For Machine Automation and Control internet sayfası www.omac.org

(Dennis Brandl’ın OMAC Users sunumunun bulunacağı adres www.omac.org/omac/arc-talks/DBrandl-BRL.ppt )



[4] Total Productive Maintenance, Rolly Angeles, RSA Reliability & Maintenance Consultancy Firm internet sayfası www.rsareliability.com

(Rolly Angeles’in dökümanının bulunacağı adres http://www.rsareliability.com/TPM%20Materials.pdf)



[5] Maintenance in History, Enrique Mora,

http://www.tpmonline.com/articles_on_total_productive_maintenance/tpm/tpmprocess/maintenanceinhistory.htm

[6] ARTESİS MCM Kullanım kılavuzu, www.artesis.com , Haziran 2009



Engin Çağlar



ARTESİS



İş ve Ürün Geliştirme Yöneticisi







Fraktaller(fractals) ve Kaos


“1) Matematik doğanın dilidir.

2)Etrafımızdaki her şey sayılarla tanımlanabilir ve anlaşılabir.



3)Rakamları hangi sistemde grafiğe dökerseniz dökün bir şablon çıkar.


Bu yüzden doğada her yerde şablonlar vardır. Kanıt, bulaşıcı hastalıkları döngüsü, dil popülasyonlarının artması ve azalması, güneş lekesi döngüleri, Nil nehrinin yükselip-alçalması.



Peki Borsaya ne demeli..? Rakamların evreni, bize evrensel ekonomiyi gösteriyor milyonlarca insan bir işte çalışıyor, milyonlarca akıl hızlı ağlar yaşamla doluyor.



Maximillian Cohen 'ın hipotezi;



Borsanın içinde de şablonlar olması……..”



Yukarıdaki bölüm, yönetmen ve senarist Darren Aronofsky’in küçük bütçeli ama harika Pi (3.14…) isimli fiminden. Filmde doğal fraktallere de görsel olarak bol bol yer verilmişti. Film 1998 Sundance Film Festivali, En iyi yönetmen ödülünü almış. Bir şekilde filmi bulup, izlemenizi tavsiye ediyorum. Ben bu yazıyı hazırlarken geçen yıl satın aldığım vcd’sini tekrar izledim ve yazının giriş bölümü için yukarıdaki alıntıyı seçtim.



Fraktaller (fractalls) ve Kaos



İlk kez altı ay kadar önce bir kitapda karşıma çıktığında bu kelimenin ne olduğunu bilmiyordum ya da bildiğim neye dendiğini bilmiyordum da denebilir. Net’te biraz arama motorlarında arayınca neyse ki bulmak çok kolay oldu. Bulmak kolay olmuştu ama benim de bu konuda devamında araştırmam, sıradaki konuların önüne geçmesi ve yazmaya başlamamda bir altı ay sürdü. Yine de bu konuda araştırma yapacak olanlara kaynak sağlayabileceği umudu ile mutluyum.



Morfik Alanlar terminoloji bölümünde tanım olarak yer verdiğim fraktallerle ilgili Sevgili Güneş gönderdiği e-mail de “Bilgisayar mucizesiyle evreni anlamaya daha yaklaştı insanlık. Bahsettiğin gibi buna en güzel örnek fraktaller. Mistik çağrışımdaki 'arşetip' olgusunun bilimsellikte örneklenmesi sanki. Ve diğer önemli kavram, evrenin temelindeki sır, yani "her noktada enerjinin değil, bilginin yaratıcı güç olduğu" fraktellerde karşımıza çıkıyor. İki satırlık bir program, başka bir ifadeyle "küçücük bir bilgi paketi" sonsuz çeşitlemelerle bir evren yaratıyor adeta.” demişti. Benim de fraktallerle ilgili yazacaklarım ve açıklamaya çalışacaklarım bu yönde olacak.



Fraktal aslında bir madename (uydurulan) kelime. Mandelbrot, kendi şekilleri ve boyutları ve geometrisi için bir isim bulması gerektiğini düşünürken, bir gün tesadüfen oğlunun Latince sözcüğünü eline alıp karıştırırmaya başlar. Sayfaları çeviriken gözüne fractus sıfatı ilişir; kırılmak anlamındaki frangere fiilinden türemiş bir sıfattı. Aynı kökten gelen İngilizce fracture ve fraction kelimelerinin sesine de uygun düşüyordu. Bunun üzerine Mandelbrot fraktal kelimesini icat etti. (isim ve sıfat olarak İngilizce ve Fransızca)



Aklın gözüne göre, bir fraktal sonsuzu görebilmenin bir yoludur. (Kaynak1)



“Tabiatçının baktığı, Pirenin biri



Olmuş daha küçük pirelerin yemi,



Var o küçük pireleri de ısıranlar,



Hikayemiz sürer böyle sonsuza kadar”



Fraktal bilim adamlarınca gökyüzünde gördüğümüz, toprakta hissettiğimiz ve bedenlerimizin damarlarında ve sinirlerinde bulduğumuz kaos örüntülerine verilen addır.



Matematikçiler değişik türlerde doğrusal olmayan (geri bildirim) formülleri kullanarak bu doğal fraktalleri taklit etmişlerdir. Ayrıntıları açısından sınırsız olmakla birlikte, matematiksel fraktaler doğal karışıklıklarının sahip olduğu süptilliteden yoksundurlar. Yine de bunlar bilim adamlarını kaosun doğal fraktalleri olası kılan gerçek hareketlerini göz önüne getirmeye daha yakınlaştırır.



Doğal bir fraktalin klasik örneği bir sahil şeritidir. Mandelbrot fraktal fikriyle zarif bir şekilde basit, ama aynı zamanda şeytani bir şekilde karmaşık bir sorunun sorulduğu bir yazı vesilesi ile tanışmıştır: Büyük Britanya'’ın sahil şeridinin uzunluğu ne kadardır? Onun yanıtı kasosun görünüşüne harukulade garip bir anlık bakışlar vermişti.



Britanya’yı bir uydu mesafesinden gördüğünüzü düşünün; bir Dünya haritasındaki Britanya. Girintili, çıkıntılı sahil şeridi kenarınca bir iplik bükün, sonra haritadaki mil ölçeğinin üstüne tutun. Deniz kıyısının uzunluğu ne kadardır? Yanıt basit gibi görünür. Şimdi, bu işlemi daha ayrıntılı ulusal bir harita üzerinden tekrar edin. Bu yeni haritada gerçek deniz kıyısının daha fazla koy ve körfezlerini görürüz. İpimizi bu haritadaki ölçek üzerinde ölçtüğümüzde, sahil şeridinin ölçüsünün daha uzun olduğunu buluruz. Oldukça ayrıntılı bir denizcilik haritasıyla daha uzun bir ölçü ortaya çıkar. Şimdi, bu işi bir de elinizde bir ip parçası ve bir metre şeridiyle, her kıvrım ve dönüşü içermeye yönelik bir çaba harcayarak yaya olarak yapmayı deneyin. Peki bu kıvrım ve dönüşlere moleküler ya da atomik düzeyde inersek? Bu mantıkla Mandelbrot Britanya’nın sahil şeridinin sonsuz olması gerektiği şeklinde şaşırtıcı bir sonuca ulaşmıştır. Buna yalnızca sahil şeridinin sonsuz olmasının yanı sıra, sürekli olarak aşındığı için aynı zamanda bunun sürekli olarak değişen bir sonsuzluk olmasını da ekleyebiliriz. Mandelbrot ayrıca en küçük ıssız adadan tutun Kuzey ve Güney Amerika’nın kendisine kadar bütün sahil şeritlerinin sonsuz uzunluğa sahip olduğunu da ortaya çıkarmıştır.



Bir sahil şeridi dalgaların ve diğer jeolojik güçlerin kaotik hareketiyle meydana gelir. Bu hareketler her ölçekte, daha büyük ölçektekine kabaca benzeyen daha küçük ölçekte bir örüntüyü tekrar eden şekiller üretir. Başka deyişle, kaos biçimler ortaya çıkarır ve kaos bilimcilerin “farklı bir çok ölçekte kendiliğinden benzerlik (self-similarty)” dedikleri şeye sahip olan izlerin arkasında bırakır.



Belirli bir ağacın şekli-tohumdaki genetik programın ve alabildiği güneş ışığı, hava durumu, hastalık, toprağın koşulları, diğer ağaçların konumu vb. de dahil olmak üzere çevredeki akışın birbirine bağlı kaotik dinamiklerin hepsi tarafından üretilmiştir-birkaç ölçekte yansıtılır. Gövde dallara, dallarda daha küçük olan ince dallara ayrılır. İnce dallar, damarlarında dentritik örüntüleri tekrar eden yapraklar içerir. Büyük ölçekli şeklinde ve küçük ayrıntılarında, bu ağaç kendisini yaratan ve devam ettiren kaotik etkinliğin an ve an, tahmin edilemez akışının kendinden benzeşimli bir kaydırır.



Hem doğanın, hem de inan şuurunun biçimlerinde var olması mümkün olan çok geniş bir fraktal kendiliğinden benzerlik dağılımı bulunmaktadır. Bazı fraktal biçimlerde –özel-likle bilgisayar ekranlarında matematiksel formüllerle üretilenlerde- kendiliğinden benzerlik bir dereceye kadar mekaniktir. Diğer fraktallerde-doğadaki ve sanattaki- kendi kendine benzerlik, bu tanıma baş kaldırırcasına farklı olan şeylerle bir arada bulunur.



Mikrokozmos ve Makrokozmos arasındaki fraktal kendiliğinden benzerlik (eşi benzeri olmama ve durumunun ve farklılığın benzersizliğini içerir) dinamik bir sistemin içinde süregiden karmaşık iç geribildirim ilişkilerinin hepsinin bir ürünüdür. Gerçekliğin fraktal özelliklerine dikkat etmek dünyayı oluşturan bir arada tutan gizemli, tahmin edilmez hareketi bir anlığına görmenin bir yoludur. Bilim düşkünü bir kültür için bu görülecek yeni bir yoldur.



Mandelbrot’un doğal dünyanın fraktal olgusunun tanıdık olduğumuz üç boyut-boy-en ve yükseklik –(çizgi, düzlem ve cisimle gösterilen) arasında meydana geldiğini gösterebilmiştir. Bir şeyin boyutlar arasında meydana geldiği fikri ile ne kast edildiğini anlamak için sıradan bir mektup kağıdını düşünün. Kağıt iki boyutluk bir düzlem, boy ve eni temsil etsin. Düzlemi buruşturup bir top haline getirin. Şimdi kaç boyutu var? Tam olarak küre değil, ama artık bir düzlem de değil.



Benzer şekilde, bir sahil şeridi de sıradan tek boyutlu bir çizgiden farklıdır. Tek düz bir çizgiden ziyade bir düzlemin yüzeyinde olabildiğince çok matematiksel noktadan geçecek derecede buruşuk ve kırışıktır. Bu durum, diyelim ki Mandelbrot, bir sahil boyunun boyutunun düz bir çizginin “biri” ve bir düzlemin “ikisi” arasında bir yerde olması gerektiği anlamına gelir.



Fraktaller bilgisayar ekranlarında ünlü Mandelbrot setiyle üretilen çok çekici soyutlamalar sayesinde halkın dikkatini çekmeye başlamıştır. Bu görüntüler matematiksel formüllerin örüntüleridir. Matematiksel formüler, bunun sonucunda, mantık kurallarının şekillendirilmeleridir. Belirli formüllerin kaotik bir güzellik içermesi gerektiği ise oldukça dikkate değer.



Mandelbrot setinden “matematikteki en karmaşık konu” olarak söz edilmiştir. (kaynak2) Karmaşık sayı düzlemi denilen matematiksel yapının bir bölgesinde kurulmuş bir sayılar çalılığıdır. Matematikçiler ve bilgisayarcılar, bu bölgedeki sayılara doğrusal olmayan (geri bildirimli) basit formül ya da bir algoritma uygulayıp, bunu bilgisayar vasıtası ile grafiğe dönüştürdüklerinde belirli bir organik niteliği olan ve sanatı andıran çok çekici görüntüler elde edebilirler.



Mandelbrot setine yakından bakıldığında, bu matematiksel objeler inanılmaz fraktal kendiliğinden benzerlik derinliğine sahiptir. Setin kendisinin büyük ölçekli görüntüsü bile mikro ölçeklerde tekrarlanır. Bunlar mini-Mandelbrotlar olarak adladırılır. Büyük ölçekli Mandelbrot’un hemen ötesinden bunları görebilirsiniz. Bu minilerin de içerisine zoom yapmak ve orjinal şeklin bir varyasyonunu görmek mümkündür.



Matematiksel fraktaller etkileyicidir, ama tekrar tekrar gördükten sonra böyle bir objenin tazeliği solar. Aynı durum, holistik bir kaotik süreçten ortaya çıkan bu sayede sayısız “bölüm” ün süptil bir biçimde birbirleriyle birbirleriyle karşılıklı bağlantı içerisinde olan doğanın yaradılışları için söz konusu değildir; bir algoritmanın tekrarlanması ile üretilen matematiksel bir taklide karşı hakiki kaos. Sonuç olarak doğal fraktaller hiç bir algoritmanın –doğrusal olmayan bir algoritmanın bile-üretemeyeceği bir eşşizlik, kendiliğindenlik, derinlik ve gizem niteliğine sahiptir.



Sayılar 1, 2 , 3,…..tamsayıları olarak kilometre taşlarıyla sınırlanmış bir hat üzerinde uzanmış olarak betimlenirler. Bu kilometre taşları arasında rasyonel sayılar-tamsayıların oranlarından çıkan sayılar – yerleştirilmiştir. Örneğin, 1 ve 2 arasında ½, ¾ , 7/8, 31/32, vb. gibi. Aslında, herhangi iki tamsayı arasında sınırsız sayıda rasyonel sayı bulunmaktadır. Ayrıca birbirlerine ne kara yakın olurlarsa olsun herhangi bir rasyonel sayı çiftinin arasında sınırsız sayıda başka rasyonel sayılar bulunmaktadır. Pisagorcular sayılarhakkında herşeyi bildiklerini hissediyorlardı. Başka herhangi bir şeyin yerleştirilebileceği hiçbir aralık, hiçbir boşluk yoktu.



Daha sonra Pisagor bir dik üçgenin hipotenüsünün karesi hakkında ünlü teoremini ortaya çıkardı. Diğer iki kenarı bir fit uzunluğunda olan bir dik üçgenin en uzun kenarını hesaplamak için bu teoremi kullandı. Sonuçta matematikte daha önce görülmemiş onu dehşete düşürecek bir sayı çıktı: 2’nin karekökü. Bu, kimsenin başka iki sayının bir oranı olarak ifade edemeyeceği irrasyonel bir sayıydı. İrrasyonel sayıyı kağıda dökmeye çalışırsak bunun hiç bir zaman sonuna varamayız. Ne kadar karmaşık olursa olsun rasyonel sayılar daima sınırlıdır ya da 1/3 gibi kusursuz bir biçimde düzenli bir şekilde (0.3333333…) tekrar ederler. Ancak irrasyonel bir sayı sonsuzdur; bir sonraki rakamın ne olacağını gösteren hiçbir iç düzeni yoktur. Daha önce sayılarla doldurulmuş olduğumuz hat üzerinde, irrasyonel sayılar kendi aralıklarını yaratır ve kendilerini buna yerleştirirler.



Bu sonuç öyle utanılacak bir şeydi ki bir süre boyunca Pisagorcu üyeler tarafından bastırıldı. Aslında, bir çemberin çapının çevresi ile ilişkilendirilen Pi Sayısı gibi doğal dünyanın derin anlam taşıyan sayılraının irrasyonel oldukları artık açığa çıkmıştır. İrrasyonellik düzenli bir sayı hattı içindeki bir süresizlik biçimidir. İrrasyonel sayılar sonsuz karmaşıklığın, başka bir türlü düzenli siztem içindeki toplam rastgeleliğin patlamalarıdır. Bu nedenle irrasyonellik hem mantık, hem de kozmozsun tam kalbinde bulunmaktadır. İrrasyonellik ayrıca karmaşıklık hakkında oldukça garip bir şeyler de sergilenmektedir.



Basit bir sistemle başlayalım ve bunun çok fazla karmaşık biçimlerde gelişmesine olanak verelim; böyle olunca, onun iç düzeni daha da zenginleşir, yine de sınırlar içinde, bu karmaşıklık sonsuzlaştığında, sonunda tamamen şans ve rastgelelik gibi-herhangi bir düzenin karşıtı- bir görünüm kazanır. Peki, bu nasıl olabilir? Bir bilgisayara basit bir kural verin; bilgisayar belirli uzunlukta bir rasyonel sayı üretecektir. Kuralı daha karmaşık bir hale getirin, bu sayı daha da büyük olacakır. Yine de bir içi düzen belirlemek her zaman için mümkündür. Bu sayıyı ikinci bir bilgisayara verin, sayının üretilmiş olduğu kuralı çözülebilecektir.



Ancak kural kağıda dökmesi birçok sayfa gerektirecek kadar karmaşıklaştığında ne olacak? Bu kuralı kağıda dökmek için sonsuz sayıda sayfaya gerek duyarsanız ne yapacaksınız? Şimdi, sayı sonsuz bir şekilde uzundur ve hiçbir iç örüntü bulmaksızın yıllarca çalışacaktır. Herhangi bir iç düzeni olmayan bir sayı tanıma göre rasgeledir. Bütün pratik amaçlar için, sonsuz karmaşıklıktan yaratılan bir sayı bu nedenle hiçbir düzeni olmayan rasgele bir sayıya özdeştir. Bu paradoksal sınırda, toplam şans ve rasgelelik sonsuz karmaşıkla özdeş bir hale gelir. Karmaşıklığı çok uzaklara itin, saf şans haline gelir. Basiti sıkıştırın, karmaşıklık patlak verir.



Matematik paradoksun bir kısmını sergiler, psikoloji ise diğer tarafını. Şu an yaşam ne kadar kaotik ve rasgele görünürse görünsün, biz aynı zamanda onun temelini oluşturan bir düzen içerdiğini hissederiz. Yaratıcı uğraşlarla meşgul olan kişiler yeni biçimler yaratmak için çekirdekler ve yollar olarak şansı kullanırlar. Kazara dökülen tuhaf bir boya, bir konuşmanın kulak misafiri olunan bölümü, bir yol işaretinin görünüşü vb. olabilir. Şans olayları yaşamlarımızdaki daha derin bazı örüntülere dair ip uçları verebilir. Psikolog Carl Jung görünüşe göre bağlantısız, ama oldukça anlamlı raslantılara “eşzamanlılık” adını vermiş ve bu gizli örüntüleri okumaya istekli olmamız gerektiğini ileri sürmüştür.



Eşzamanlılık diyince, Eşzamanlılık ve Morfik Alanlar araştırmamdan sonra aldığım bazı e-maillerde, okuyan kişilerinde eşzamanlılık deneyimi yaşadığını öğrendim. Bir kaç örnek vereyim: Yazıyı makinasına save edip, off line okuyan okurken radyoda, benim o yazıya fon müziği olarak seçip, koyduğum müzik çalmaya başlamış. Diğer bir mailde, başka ülkede yaşayan hanım yazıyı okuduktan sonra, Kablo TV’den rasgele bir film seçtiğini, filmi yarısı olduğunu filmin adının ne olduğuna program kitapçığından baktığında ise Xanadu olduğunu görüp çok şaşırdığını yazmış.



Aslında fraktallin tanımı ve işlerliği ile hologram’ın tanımı arasında da benzerlik görünüyor, hologram için bu sitedeki Hologram Teorisi içinde şöyle demiştik “



Hologramın tek şaşırtıcı özelliği üç boyutlu oluşu değildir. Üzerine bir elma imgesi kaydedilmiş bir holografik film parçasını ikiye böler ve ve sonra parçaları lazerle aydınlatacak olursak, her iki yarının da elma imgesinin bütününü kapsamakta olduğunu görürüz! Bu yarım filmleri tekrar tekrar bölerek yine aynı işlemi yineleyecek olursak, bütün elma imgesinin en küçük parçanın üzerinde bile (parçalar ufaldıkça imgeler biraz flulaşmakla birlikte) yer aldığını görerek yeniden şaşırabiliriz. Normal fotoğrafların tersine, holografik bir film parçasının en ufak parçası, bütün üzerinde kaydedilmiş tüm bilgileri kapsamaktadır.” Konuyu fazla dağıtmamak için sadece dikkatinizi çekmekle kalacağım.



“Fraktal nesneleri gelişigüzel bir algoritma ile sondalamak sayesinde çok ayrıntılı enformasyon elde ediyoruz. Bu tıpkı şuna benzer: yeni bir odaya girdiğimizde, gözlerimizi bu odanın içinde belirli bir sıra ile gezdiririz, bu belkide gelişi güzel bir sıradır; böylece oda hakkında iyi fikir elde etmiş oluruz. Oda ne ise odur. Nesne benim ne yaptığımdan tamamen bağımsız olarak mevcuttur.” (kaynak1)



Mandelbrot Kümesi de, aynı şekilde mevcuttur. Mandelbrot kümesi, Peitgen ve Richter, onu bir sanat biçimi haline dönüştürmeden öncede. Hubbard ve Douady onun matematik özünü anlamadan önce de, hatta Mandelbrot onu keşfetmeden önce de mevcuttu. Bilim kendisine bir içerik yarattığı-yani kompleks sayılardan oluşan bir çerçeve ve iterasyonlu fonksiyonlar yaklaşımı yarattığı- andan beri mevcuttu. Ondan sonra oturup, sırrının çözülmesini beklemiştir. Hatta belki daha önce de, doğa, sonsuz bir sabırla ve her yerde aynen tekrarladığı basit fizik yasalarını kullanarak organize olduğu andan beri mevcuttu.



“Bütünü cebinize koyamazsınız, bunun nededi cebinizin bütünün bir parçası olmasıdır. Bu nedenle kendi içinde bir boşluğu vardır" (kaynak2)



Bir şeyleri atlamadan irrasyonel bir sayıyı asla yuvarlayamazsınız. Atlamış olduğunuz şey de bilginizdeki bir boşluktur.



Edward Lorenz ikinci hava durumu tahmininin ilkine uymadığını bulduğunda, onun da sorunu bu kayıp bilgiydi. Lorenz’in deneyimine yer vererek devam edelim:



“1961 yılının kış aylarında bir gün, Lorenz bu ardışık sayı dizilerinin birini uzun uzadıya incelemek istediği bir sırada kestirme bir yol izlemeye kalkıştı. Programı tekrar başa dönüp çalıştırmak yerine ortalarda bir yerden başladı. Makineye başlangıç durumundaki şartları vermek için, daha önce yazıcıdan çıkardığı dizilere bakıp oradaki sayıları klavyeden aynen girdi. Sonra da hem makinanın gürültüsünden kaçmak, hem de bir fincan kahve içmek üzere koridorun sonundaki hole gitti. Bir saat kadar sonra döndüğünde hiç ummadığı bir şeyle karşılaştı; hem de öyle bir şey ki bununla artık yepyeni bir bilim dalı filizlenmeye başlıyordu.



Bilgisayarın yaptığı bu dökümde bir önceki dökümün tıpatıp tekrarlanması gerekirdi. Lorenz aynı sayıları makineye kendi elleri ile girmişti. Programda bir değişiklik yoktu. Oysa Lorenz yazıcıdan yeni çıkan döküme baktığında gördüğü şey şuydu: Hava durumu bir önceki dökümde yer alan şekilden o kadar hızla uzaklaşmaktaydı ki, bir kaç aylık bir süre zarfında, aradaki bütün benzerlik ortadan kalkmıştı. Lorenz bir bu sayı kümesine baktı, bir de önceki sayı kümesine. Sanki bir şapkanın içinden rastgele iki hava durumu seçip almış gibiydi. İlk aklına gelen şey, gene vakumlu tüplerden birinin bozulduğu oldu.



Birden gerçeği farkına vardı. Makina bozulmuş falan değildi. Mesele makinaya işlediği sayılardan kaynaklanıyordu. Bilgisayarın hafızasına kaydedilen ondalık kesir sayıları altı haneydi: .506127. Yazıcıdan çıkan dökümde ise yerden kazanmak için, sadece üç hane görünüyordu: .506. Lorenz sayıları kısaltarak son üç rakamı yuvarlamış, binde birlik bir farkın sonucu etkilemeyeceğini düşünmüştü.



Aslında bu varsayımın akla aykırı bir yönü yoktu. Bir meteoroloji uydusu okyanusun yüzeyindeki sıcaklığı binde birlik bir hassaslıkla okuduğunda, uzmanlar kendilerini şanslı addediler. Lorenz’in Royal McBee’si klasik programı uyguluyordu. Tamamiyle determinizme dayalı denklemler sistemi kullanmaktaydı. Belirli bir çıkış noktasından hareket edildiğinde hava durumunun her seferinde tıpatıp aynı gelişmeyi göstermesi gerekirdi. Biraz daha farklı bir çıkış noktasından hareket edildiğinde, hava durumunun da biraz daha farklı bir gelişme göstermesi gerekecekti. Küçücük bir sayı hatasının rüzgarın hafif esintisinden farkı yoktu; tabi ki hafif esintiler hava durumunda önemli, büyük ölçekli değişimleri getirmeden önce ya zayıflayıp ortadan yok oluyorlar ya da birbirlerini dengeliyorlardı. Oysa Lorenz’in kendine özgü denklemler sisteminde küçücük hatalardan büyük felaketler doğmaktaydı.



Bunun üzerine Lorenz birbirinin hemen hemen aynı olan iki hava durumu işleminin birbirinden bu kadar nasıl uzaklaştığı konusunu daha yakından incelemeye karar verdi. Çıktılardaki eğrilerden birini saydam bir kağıda kopyaladıktan sonra diğerinin üstüne tatbik ederek ne tarz bir ayrılık gösterdiğini tespit etmeye çalıştı. İlk başta, ne tarz bir ayrılık grafikteki iki yüksek nokta en küçük ayrıntısına kadar çakışıyordu. Sonra eğrilerden biri kıl payıyla diğerinin gerisinde kalmayı başlıyordu. İki işlem devam edip, eğriler bir sonraki yükseliş pozisyonuna geldiğinde, artık aralarındaki uyum gözle görülür derecede kaybolmaktaydı. Üçüncü veya dördüncü yükseliş noktalarında, artık aralarında hiç benzerlik kalmamıştı.



Ancak, bu noktada Lorenz’in matematiksel sezgisinden kaynaklanan bir takım nedenler devreye girdi. Felsefi açıdan bakıldığında bir şeyler yerli yerine oturmuyordu. Oysa, olay uygulama açısından akıllara durgunluk verecek derecede büyük önem taşıyordu. Bu denklemleri aslında dünyamızın hava durumunu üstünkörü bir şekilde canlandırmak amacıyla kurmuş olmasına rağmen, içinden bir ses aynı denlemlerle gerçek atmosferin özünü yakalamış olduğunu söylüyordu. Bu ilk günün neticesinde, uzun süreli hava durumu tahmininden bir sonuç alınamayacağına hükmetti.



Karmaşık sistemlerin modellenmesinde bilgisayarların ilk kullanıldığı alan olarak hava durumu tahmini, böylece yepyeni bir alan açılmasını sağlamış oluyordu. Uskur dizayncılarını ilgilendiren en küçük ölçekli sıvı akışlarından, ekonomistleri ilgilendiren geniş çaplı para akışlarına kadar her alanda ileriye dönük tahminlerde bulunmayı ümit eden araştırmacılar, ister tabii bilimci olsun, ister sosyal bilimci olsunlar hep aynı tekniklerden yararlanmışlardır. Hakikaten, yetmişli ve seksenli yıllarda, bilgisayarlarla ekonomik durum tahmini yapma konusu global hava durumu tahmini yapmak konusuyla gerçek anlamda bir benzerlik göstermiştir. Modeller, başlangıç durumundaki-atmosfer basıncı ya da para arzı gibi-şartların ölçümünü gelecekteki trendlerin simülasyonuna dönüştürmek amacıyla düzenlenmiş olan karmaşık denklemlerle içi içe girip karışmıştır. Programcılar, önlenmesi mümkün olmayan sadeleştirme varsayımları dolayısıyla sonuçların olmayacak şekilde çarptırılması beklentisi içinde olmuştur. Model, - Büyük Sahra’yı sel bastırmak ya da faiz oranlarını üç katı yükseltmek gibi – göze batacak derecede acaip bir şeyler yapmaya kalkıştığında programcılar denklemleri tekrar elden geçirip, sonucu olması gerektiği şekle sokmuşlardır. Uygulama bakımından, geleceğin getireceği olaylar konusunda ekonometrik modellerin gözleri malesef bağlı kalmış, üstelik bunu en iyi bilmek durumunda olan pek çok kimsede alınan sonuçlara inanmış gibi davranmışlardır. Ekonomik kalkınma ya da işsizlikle ilgili tahminler açıkça söylenmemekle birlikte iki ya da üç ondalık kesirlik bir hassaslıkla ifade edilmiştir. Hükümetler ve finansal kurumlar, ya ihtiyaç duydukları ya da işsizlikle ilgili tahminleri bedeli karşılandığında sağlamış ve icraatlarını bunlara dayandırmışlardır. Muhtemeldir ki, “tüketicinin iyimserlik katsayısı” gibi değişkenleri “nem oranı” gibi kolaylıkla ölçmenin mümkün olmadığını, üstelik politik hareketler ve moda için henüz mükemmel diferansiyel denklemler yazılmamış olduğunu onlar da biliyorlardı. Ne var ki, akış olayını bilgisayarda modelleme süresince çok fazla ümit bağlanamayacağını bilenlerin sayısı pek azdı; hatta mevcut verilerin yeterince güvenilir sayılması ve hava durumu tahmini alanında olduğu gibi, kanunların tamamen fiziksel olması halinde bile durumda fark yoktu.



Bilgisayarlı modelleme evvelce sanat sayılan meteorolojiyi bilime çevirmekte gerçekten başarılı olmuştur. Avrupa’daki merkezce yapılan değerlendirmelere bakılırsa dünyada heryıl hava durumu tahminleri sayesince milyarlarca dolar tasarruf edilebilirdi; istatistik açısından da bakılırsa bu tahminlere sahip olmak elde hiç bir şey olmamaktan daha iyi idi. Ne var ki, dünyanın en iyi hava tahminleri bile iki, üç günden öteye gitmiyor, bu süreyi aştığında spekülasyona dönüşüyordu.



Bunun sebebi Kelebek Etkisi (*) idi. Meteorolojideki küçük olaylar açısından bakıldığında (global ölçekte bakarsanız küçük olaylar denilince fırtınalar ve tipiler kastedilir) her tahmin hızla değer kaybeder. Hatalar ve belirsizlikler çoğalmakta, zincirleme olaylar halinde gittikçe azalarak anafor ve boralardan sadece uydulardan görülebilecek şekilde bütün kıtaya yayılan burgaçlara kadar şiddetini arttırmaktadır. “ (Kaynak1)



* Kelebek Etkisi : Başlangıç durumundaki şartlara hassas bağımlılık. Gerçek hayatta olduğu gibi bilimde de, birtakım zincirleme olaylarda küçük değişiklikler çok büyük sorunlar haline getiren bir kriz noktası bulunduğu bilinir.



Kayıp bilgiyi kaos teorisinin hilekarı olarak düşünün!!!



“Bugün geriye dönüp baktığımızda, Doğa'nın sembolik dili olarak gördüğümüz sayıların etkisini, o asla bozulmayan analojiyi görür ve sorarız: Dünya neden böyle ve Doğa'nın işleyişini çözmemizi ve öngörmemizi sağlayan matematiğin şu ilginç dili neyin nesi? Kısacası, onu biz mi icat ettik yoksa keşfettiğimiz bir şeyin parçasımıydı? Eğer onu keşfettiysek, bu onun bizden bağımsız olarak varolduğu anlamına mı geliyor? Eğer böyleyse nerede varoluyor? Kesinlikle içinde yaşadığımız zaman ve mekanda değil, çünkü onlar aynı matematik tarafından tanımlanabiliyor. Ama eğer başka bir alanda varoluyorsa, biz diğer matematiksel biçimler dünyasıyla nasıl oluyorda temas kuruyoruz?” (kaynak6)



“Matematik sadece bir analojimidir, yoksa belirli düşüncelerden oluştuğumuz fiziksel gerçeklerin yapıldığı maddemidir? “ (kaynak6)



Hülya Xxanadu



17.02.2002



Kaynaklar:



Kaos, James Gleick, Tübitak Popüler Bilim Kitapları.

Kaos ve Yedi Yaşam Dersi, John Briggs & F. David Peat, Ege Meta Yayınları.

Kaostan Düzene, İlya Prigogine & İsabelle Stengers, İz Yayıncılık.

Bu sitedeki Eşzamanlık ve Morfik Alanlar bölümündeki kaynaklar.

Bu sitedeki Hologram Teorisi bölümündeki kaynaklar.

Gökteki Pi, Saymak, Düşünmek ve Olmak, John D. Barrow, Beyaz Yayınları.

Dip Notlar:



Bir fraktal programı edinmek istiyorsanız, “fractal maker download” gibi bir anahtar kelimelerle ile arama motorlarında bulabilir ve down load edebilirsiniz.



Sn. Sinan Canan’ın sitesinde ki fraktallerle ilgili bölüme de bakınız.





Friday, September 24, 2010

27.Ulusal Bilişim Kurultayı




Bilişim 2010 - Açılış töreni ve 1. günün özeti


2010'da 'Sosyal Dönüşüm' sloganıyla organize edilen Bilişim 2010'un ilk gününü geride bıraktık

Ülkemizde düzenlenen en büyük ve kapsamlı bilişim etkinliği Bilişim 2010, 22 Eylül 2010 tarihinde düzenlenen açılış töreniyle başladı.



“Sosyal Dönüşüm” ana temasıyla gerçekleşen etkinliğin açılış konuşmalarını Türkiye Bilişim Derneği Yönetim Kurulu Başkanı Doç.Dr.Turhan Menteş ve Bilgi Teknolojileri ve İletişim Kurumu Başkanı Tayfun Acarer yaptı.



Doç.Dr.Turhan Menteş konuşmasına : ‘’On binin üzerinde üyesi olan ve 1971 yılında kurulduğunda adında ‘Bilişim’ sözcüğü olan Türkiye Bilişim Derneği’nin; Ankara, İstanbul, İzmir, Bursa, Samsun Antalya Şubeleri, 20 ildeki temsilcilikleri ve 30’u aşkın üniversitedeki TBD Genç örgütlenmesi ile Türkiye’nin bilişim toplumu olması yolunda, ilerlemesini yönlendiren ve destekleyen, gönüllülük esası ile çalışan ülkemizin en büyük sivil toplum örgütü olduğunu anlatarak başladı.



Turhan Menteş konuşmasına şöyle devam etti. ’’Geçtiğimiz yıllarda Geleceği Görmek, Ortak Akıl ve Ufkun Ötesi gibi geleceğe yönelik tematik konularla gerçekleştirilen bu etkinlik evvelki sene Yakınsama ve geçen senede Teknoloji Politikaları ana teması ile gerçekleştirilmiştir. Bu sene de ana tema olarak Sosyal Dönüşüm seçilmiştir.



Ülkemiz, son 20 yıllık geçmişinde en iyi fen kafalarını bilgisayar ve elektrik ve elekronik mühendisliği ve yan alanlarında yetiştirmiştir.Bu kesim üniversitelere binde birlik dilimden girmekte ve üstün nitelikle mezun olmaktadırlar. Ancak bu nitelikli uluslararası rekabet gücüne sahip bu birikimimizi, bizler hala bir itici güce çeviremedik, bu kesim için uygulanabilir bilişim politikaları belirlemedik.



Özel belirlenmiş politikalarla bilişim sektörünün oynayacağı rol, Türkiye’nin dünyanın en büyük ekonomileri arasına girmesindeki hızını artıracak ve oradaki gücünü kalıcı hale getirecektir.



Ülkemizde büyük bir başarı ile uygulanan kamu bilişim projeleri var. Son 30 yıldır neredeyse bilişim sektörünün yarıdan fazla yatırımını yönlendirdiğimiz kamu bilişim projeleri sayesinde sağlanan kurumsal bilgi birikimini, ilgili kurumların Türkiye’nin hedef pazarlarına giderken beraberinde götürmesini sağlamak hedefimiz olmalıdır. Mernis, Vedop, Uyap, Gümrükler gibi projelerimizin çoğu gelişmiş AB ülkelerinde bile yoktur.



Bu amaçla kurumlarımızın özellikle de devlet üst yönetimi gerçekleştirdiği her türlü uluslararası ilişkilerde, bilişim çözümlerini vurgulamaları ve ülke projelerimizi ihraç etmek amacıyla yönlendirmeleri gerekmektedir. Bu çalışma, sektörümüzün yurt dışındaki etkinliğinin artmasında büyük bir rol oynayacaktır. Bu projeler gelecek getirileri öngörülerek, hazır projelerimiz teknolojik veya hibe yardım olarak sunulmalıdır.



Bunun için de kamunun iş yapma alışkanlıklarını değiştirecek değişikliklere gidilmesi de kaçınılmazdır.



Bir diğer hedef kamunun belirlediği hedefler doğrultusunda ihtiyacı olan bilişim teknolojileri çalışmalarınında kamu-özel sektör ortaklığı modelinin etkinleştirilmesi ve yaygınlaştırılması olmalıdır. Bu konuda son iki yılda ortaya çıkan durum süratle değerlendirmeli rekabeti önleyici yapılanmalardan kaçılmalıdır.



Yazılım sektörünün stratejik bir sektör olarak ele alınması hayati öncelik taşımaktadır. Ülkemizin diğer stratejik sektörlerinden farklı olarak; yazılım sektörü, uluslararası rekabetçilik için bir fırsat sunmaktadır. Bu fırsat, Türkiye’nin ekonomik ve sosyal gelişiminde büyük önem taşıyacaktır. Bu nedenle YASAD sunumunun tarafınızdan iyi değerlendirileceğini umuyorum’’



Bilişim etkinliklerinde geleneksel olarak yayınladığımız yıllık Değerlendirme Raporumuz, bu yıl da 89 özel sektör, kamu ve sivil toplum kuruluşlarının üst düzey yöneticileri ile akademisyenlerin ortak görüşü ile hazırlandı. Rapor baskısı yetişirse bu akşam dağıtılacak. Bu raporun en önemli özelliği bir izleme raporu olması ve bir yıl sonraki hedefleri de belirlemesidir. Bugün zaman kısıtı nedeniyel söyleyemediğim tüm konular bu raporda yer almaktadır.Bu raporun karar vericiler tarafınan gereği biçimde değerlendirileceğini umuyoruz’’



Açılışta konuşan Bilgi teknolojileri ve İletişim Kurumu Başkanı Tayfun Acarer, kurumları ve Ulaştırma Bakanlığı bünyesinde gerçekleştirilen bilişim projelerine değindi ve Bilişim sektörünün stratejik ve öncelikli bir sektör olarak kabul edilmesi gerektiğini vurguladı.Ve özellikle üniversitelerin bilişim sektörüne daha fazla katkı vermesi gerektiği konusunda dikkat çekti.

Açılış tören içinde TUBİSAD ve Türkiye Bilişim Derneği tarafından düzenlenen Bilişim Hizmet Ödülleri töreni de yapıldı. Yapılan törenle, Prof.Dr.Bülent Sankur’a Yaşam Boyu Hizmet Ödülü verildi. Prof. Sankur yaptığı konuşmada özellikle Bilişim terimlerinin Türkçeleşmesi ve bu konudaki duyarlılığın artırılmasına değindi ve üniversitelerdeki Bilişim projelerinin bir yapı altında toplanması konusundaki isteğini dile getirdi.



Açılış gününün ilk konuşmacısı Prof.Dr.Peter Levin oldu. Profesör Levin, konuşmasında, Beyaz Saray tarafından başlatılan Açık Devlet ( Open Government Inititative at White House ) inisiyatifinin hangi ilkeler doğrultusunda ve nasıl kurulduğunu ve şu ana kadar almış oldukları sonuçları anlattı.



Son konuşmacı Sunay Akın ise bilişim toplumu olmak için önce kendi değerlerimizi sorgulamamız gerektiğini vurguladı. Ve ağırlıklı olarak "Bakmak ile görmek farklı şeylerdir" teması üzerinde durdu. Sunay Akın konuşmasını bitirdikten sonra kokteyle geçildi. Böylece ilk gün sona erdi

Friday, September 17, 2010

Oyun Yazmak

Öncelikle, bir bilgisayar oyunu yapabilmek için neler gereklidir neler değildir. ne bilirsen yaparsın ne bilirsen yapamazsın bi bakalım.

sadece programlama bilmek oyun yazman için yeterli değil. çok başarılı bir bilgisayar programcısı olabilirsin. ama uzay geometrisi hakkında bilgin yoksa yada yeterli değilse, oyun yapmaya kalktığında yapabileceğin iki şey vardır. ya başkalarının yazdığı kodları bir araya getirmek, yada debelenmek.

sadece 3d grafik editörleriyle 3d objeler veya sahneler yapabiliyor olmak oyun yapabileceğin anlamına gelmez. 3d oyunlar özellikle, bir ucundan matematiğe bulaşmak demek. çok ileri olmasa bile bir çok şeyi bilmen gerekir. vede yazılım konusunda algoritma denen, programların akış mantığını kurabilme ve geliştirebilme yeteneklerinin uzmanlık seviyesinde olması gerekir.
bütün bunlara sahip olsan bile, bir bilgisayar oyunu yapabilmek için bunlardan daha önemli birkaç şeye daha ihtiyacın olacak.


1. senaryo!
2. anlatım ve kompozisyon yeteneği
3. sinematografi ve kurgu.
4. ses....
bilgisayar oyunları yapmaya kalkan insanlar ses olgusunu neden hep umursamaz davranır? görüntü ve hareketler ses olmadan br işe yaramaz. en sevdiğiniz bilgisyar oyununu sesi kapatıp oynamayı deneyin. ne zevk alırsınız?
6. uzman seviyede donanım bilgisi
7. ticari düşünüyorsan satış ve pazarlama yetenekleri.
8. ticari düşünüyorsan hak hukuk kanunlar ve izinler hakkında bilgiler. ( bunu bir danışmanla da halledebilirsin )
9. ......
falan filan..

tabi böyle bir ekiple dünyaya hitab edecek bir oyun geliştirebilirsin.
ama evde kendi başına yapmak istediğinde nelere ihtiyacın olacak bir bakalım
herşeyden önce yazılım bilgisine..

hangi yazılım dilini kullanmak lazım?

aslında windows api´lerini kullanabilen herhangi bir yazılım dili ile 3d oyun geliştirebilirsin. windows apilerini kullanabilen yazılım dilleri genelde oyun gibi karmaşık yazılımları geliştirmeye yetecek özellikleri barındırırlar.
ama hangisiyle yazarsak ne olur bir bakalım.

visual basic = küçümsenmemesi gereken bir yazılım. ancak unutmamak gerekir ki, 3 kuruşluk işi 5 mb´lik exe haline getiren ve tamamen windows form uygulamaları yazmak için geliştirilmiş bir yazılım dili olmasından dolayı, ve bu tip uygulamaların çok yüksek işlemci performansına ihtiyaç duymayacağı göz önüne alınarak donanımı kullanma ve aç gözlülük özelliklerinin bastırılmasına pek dikkat edilmemiş ve böylece kolay geliştirilen yazılımlar yapabilme yeteneği kazandirilmiş bir yazılım dilidir. ama bir grafik uygulaması işlemler sırasında bilgisayarın bütün donanım yeteneklerini sınırlarına kadar zorlayabilir. ama sizin yazılımın grafik hesapları yapması gerektiği anda, donanımınız sizin yazılımın ram´e yüklediği, aslında kullanmadığı bir kaç dll dosyasının fonksiyonlarını parselleyip makine dilinde nasıl işleyeceğini yorumlamakla meşgul oluyor olacak. yazılımınıza ekleyeceğiniz her timer komponenti, her text girdi alanı, her komponent, bunun gibi dll yığınları ve fonksiyon yığınları ile yazılımınızı şişirecek.
bunun şöle bi avantajı da var tabi. bir işlem yaptırılması gerekiyosa nası yapacağınızı bilmiyosanız ve öğrenmek için çok uzun zaman harcamanız gerekiyosa bir komponent yerleştiriverip çözüverirsiniz. ama o zaman siz zaten yazılımcı da değilsiniz :) vb kullanıcıları, alınmaca yok...

delphi bu konuda vb´den daha gelişmiş ve çok daha üstün olmasına rağmen c++´nın gücüne yetişecek bir yazılım dili deildir..
gelelim c++´a

neden herkes c++ der? derdi nedir bu insanların.

çoğu kişi, internetteki tutoriallerden oyun c++´da yazılır diye okuduğundan c++ kullanacaksın vb ile oyun yapılmaz! der.aslında yapılır. ama yeterli verimlilikte olmaz demesi gerektiğini bu yüzden bilmezler.

c++ , bilgisayarların konuşma diline ( 1010011110010101 ) en yakın dil olan assembly diline en yakın programlama dili diyebiliriz. yani c++´dan bir adım aşağısı assembly dili. assembly dilinin bir adım aşağısı da işlemciye ram´den giden elektrik sinyalleri.

visual basic ise c++´dan üç adım yukarısı oluyor.

adımları aşağı indikçe, programcının yazması gereken kodlar ve düşünmesi gereken işlemleri kurgulama gibi şeyler çoğalır. ama, yazdığı yazılım bilgisayarın diline çok yakın olduğundan bir kaç dile çevrilerek deforme olmaz. ve taşıdığı anlamlar çok değişmez.


şimdi sizin fransıza vermeniz gereken ve 1 sayfa da yazdığınız yazı. üç beş dil dolaşıp fransız´a vardığında 5 sayfaya çıkıyor. ve belki sizin yazmadan üç cümle ile anlatabileceğiniz bir konu için fransız 5 sayfa yazı okumak zorunda kalıyor.

eğer assembly gelişmiş uygulamalar yazmak için uygun bir ortam olsaydı assembly ile şu an bildiğiniz yazılımların 2 katı hızda çalışan yazılımlar geliştirmek mümkün olurdu. aynı donanımda iki kat performans kim istemez. ama assembly bu kadar gelişmiş uygulamalar yazmak için fazla karmaşık ve zordur. bu yüzden ikinci kademe olan c++ ve java gibi yazılım dilleri geliştirilmiştir.



c++ genellikle windows ve linux ortamlarının yazılım geliştirme dili olarak tercih görmüş. java ise sun firmasının geliştirdiği solaris gibi işletim sistemlerinin temel yazılım geliştirme dili.



windows ortamında c++ ile yazacağın yazılımlar diğer dillerde geliştireceğin yazılımlara göre çok daha az donanım performansı harcayacak, çok daha küçük boyutlarda olacak ve çok daha kararlı çalışacaktır.

bu yüzden windows ortamındaysan oyun yazmak için c++ kullanacaksın derler. öyle bir şart yok. ama c++ ile yazarsan en iyi performansa sahip olacaktır.

şimdi gelelim c++´ya. bu dil, yukarılarda bir kaç arkadaşın değindiği gibi herşeyi kendin yap dilidir.

burda bir windows penceresi açabilmek için hazır formun olmayacak. windows penceresinin açılması ile ilgili kodları kendin yazıcaksın.

çeşitli butonlar yok. ya windows apileri kullanarak windows´un temel form komponentlerini kullanıcaksın. yada kendi butonlarını kendin yapıcaksın.

ve gelelim 3d yazılımına. burda opengl yada directx komponenti yok. opengl ve directx uygulamanı geliştirmek için, bu grafik apilerinin nasıl çalıştığını ve nasıl programlandığını bilmen gerekecek.
peki nedir directx ve opengl.

bunlar, 3d grafiklerin bilgisayarın grafik işlemcisinde ( ekran kartında ) hesaplanmasını sağlayan bir çeşit ara programlama dilleridir. windows api´si de denir.

öncelikle hangi yazılım dilini kullandığına bakmadan. opengl programlamayı veya directx programlamayı yada aynı anda her ikisini birden programlamayı biliyor olman gerekir.

peki bunları bilmeden grafik uygulaması yazamaz mısın?
yazarsın tabi.

biraz dik üçgen formülleri bilmen gerekir. uzay geomtetri konusunda akademik eğitim almış olman gerekir. falan filan
mesela basit bir perspektif görüntüsü almak için sahnedeki her 3d kütlenin her üçgeninden kameranın fokus noktasını ışınlar çizmeli, ışının görüntü düzlemini hangi noktada kestiğini hesaplamalı, ve bu kestiği noktaları baz alarak üçgenin görüntü düzlemine nasıl izdüşüm bıraktığını hesaplamalısın. tabi bunu yaparken, sahnedeki başka üçgenler, fokus noktası ile üçgen arasına girmiş mi onu hesaplamalısın.girmişse üçgenin o köşesini değil, diğer üçgenin kestiği yerde oluşması gereken yeni köşelerin iz düşümlerini hesaplatmalısın. tabi onları hesaplatırken başka üçgenlerle kesişiyor mu onu hesaplatmalısın. bütün bunları yaptıktan sonra, ışık kaynakları ile bu ücgenlerin pozisyon mesafe ve açılarını hesaba katıp üçgenin aydınlanmasını hesaplamalısın. daha sonra üçgenin üzerine bir resim kaplanmışsa bu resmin iz düşüme göre nasıl deforme olduğunu pixeller üzerinde işlemler yaparak hesaplatıp iz düşüm üzerine kaplamalısın. aydınlık değeri be başka material özelliklerini dikkate alarak bu sonuç iz düşümleri kompoze edip sonuç görüntü olarak saniyede en azından 30 kere grafik uygulamasını takip eden kişinin monitöründe sergiletmelisin. tabi bütün bunları yapacak olan işlemci bilgisayarın matematik işlemcisi. yani yazılımın diğer işlemleri yapmak için yeterli preformansa ihtiyaç duyduğunda elinden gelecek tek şey, sahnende mümkün olduğunca az üçgen olması.

sanırım opengl yada directx öğrenmek daha mantıklı. çünkü opengl veya directx bu yukardaki işlemleri bizim yerimize yapan. ve daha önemlisi yüzlerce akademi eğitimi almış uzmanın ortak çalışması olan birer yardımcı kütüphanedir. visual basic´deki komponentler gibi. ama güzel olan tarafı, bu komponentlerin ekran kartında hesaplanması. opengl ve directx kullandığınızda 3d görüntünün hesabı için bilgisayarın matematik işlemcisi çalışmaz, grafik işlemcisi çalışır. bu yüzden ne kadar karmaşık bir sahne kullanabileceğiniz ancak yazılımın çalışacağı bilgisayarın grafik kartı ile alakalıdır :)...

peki directx ne opengl ne

directx microsoft´un geliştirdiği yazılım temelli bir grafik hızlandırma uygulamasıdır.

directx, ilk başlarda windows uygulamalarının grafik işlemlerini hızlandırmak ve basitleştirmek için düşünülmüş bir grafik kütüphanesiydi. daha sonradan 3d grafiklerin ev bilgisayarlarına düşmesiyle 3d grafik hızlandırma kütüphanesine dönüştürdüler. daha sonradan 3dfx firmasının directx ve kendi kütüphanelerini kullanarak 3d grafikleri hesaplamak için geliştirdikleri ekran kartları çıkınca, directx tamamen bir 3d ve 2d grafik hızlandırıcı olarak bilgisayarın grafik işlemcisini kullanan, grafik işlemcinin desteklemediği işlemler için de bilgisayarın kendi işlemcisini kullanan kütüphaneye dönüştü.

şimdi de hala öyle, 2d grafik, video ve 3d grafikleri çok daha hızlı hesaplamak için grafik kartını kullanan, grafik kartının desteklemediği işlemler için de bilgisayarın matematik işlemcisini kullanan bir kütüphanedir. eğer grafik kartınız directx´in bütün fonksiyonlarını tam desteklemiyorsa, ve siz yazılımınızda bu desteklemediği bir fonksiyon kullanıyorsanız, bu işlem bilgisayarın matematik işlemcisinde hesaplanacağından, bu fonksiyon yazılımınızda sıkca tekrar eden bir şey ise, yazılımınızın çok ağırlaşmasına sebep olacaktır. directx´i tam destekleyen grafik kartlarında windows ortamında en iyi grafik hızlandırıcı kütüphanedir diyebiliriz.

( 3ds max kullanıcıları grafik kartı directx 8.1´i tam destekleyip 9.0c´yi tam desteklemezken max´i directx 9 modunda çalıştırdıklarında daha yüksek performans alacaklarını düşünseler de daha az poligonla çalışmak zorunda kalırlar. çünkü grafik kartının desteklemdiği directx 9 fonksiyonları matematik işlemciye gönderilecek.. bu da sistem performansını düşürecektir. )



öte yandan directx öğrenme süreci uzun olan ve uzmanlık isteyen bir kütüphane olduğundan amatör işler için biraz ağır gelebilir.

opengl, directx´den çok daha önce geliştirilmeye başlanmış. sgi ( silicon graphics ) isimli firmanın çok eskiden beri bilimsel araştırmalarda kullanılan 3d grafiklerin hızlı ve kaliteli hesaplanması için geliştirdiği bir grafik kütüphanesidir. daha sonradan opengl bağımsızlaştırılıp açık bir kütüphaneye dönüştürülerek adı opengl, yani açık grafik kütüphanesi şeklinde değiştirilmiş. silicon graphics, tamamen kendi geliştirdiği bilgisayar donanımları üzerine, bu kütüphaneyi temel alan vertex işlemci, poligon işlemci, texture işlemci gibi, çeşitli işlemciler yerleştirerek ve ışık hesaplarını da yazılımsal olarak çözerek halen gerçek zamanlı opengl temelli fotogerçekçi renderlar yapan çok yüksek kapasiteli süper bilgisayarlar yapmaya devam ediyor.

opengl ise bu sgi´nin pc´lerinde kullanılanın x86 pc sistemlerine uyarlanmış hali. 3dfx firmasının dağılması sonucu kurulan nvidia firmasının bu kütüphaneyi grafik kartlarında kullanması ile ev bilgisayarları dünyasına girmiş, ve ilk olarak id software´in quake 3 oyununda başarılı olarak ( başarılı olarak diyorum. daha önce de uygulanmış.. ) kullanması ile opengl grafiklerinin yüksek performansı ve kalitesini görmüş olduk. opengl tamamen grafik donanımında hesaplanır. yazılımsal desteği yoktur. yani bir grafik kartı opengl´yi ya tam destekliyordur. yada desteklemiyordur. günümüzde opengl 2.0 sürümünde. daha önce 1.0 ve 1.1 sürümleri vardı. 2.0 sürümünde opengl´ye shader programlayabilme özelliği kazandırılmış. 32 bit derinlikli renk işleme özelliği kazandırılmış. video kütüphaneleri kazandırılmış ve directx´in %100 alternatifi olmuştur. tahminimce x64 sistemi pc´ler ve işletim sistemleri piyasaya oturduğunda opengl´ye gerçek zamanlı global ışıma desteği de ekleyeceklerdir. özellikle geliştiricisi olan sgi firmasının dünyanın en büyük bilimsel araştırma merkezlerine süper bilgisayarlar temin ettiği ve günümüz 3d´sinden on yıl ileride olan grafik işlemleri ile uza haritaları falan çıkartmak gibi işlerde kullanıldığından opengl´nin geleceği directx´e göre daha parlak. bir de, opengl ile yazdığınız grafik yazılımlarını biraz modifiye ederek linux yada machintosh sistemlerine dönüştürmeniz mümkün. ama directx sadece windows ortamının grafik hızlandırıcısı.



eğer bu işi ilerde yapacam diyorsan iki kere düşünmen ve üçüncüde karar vermen en doğrusu. bu konuda ilerlemek ve uzman olmak istiyorsan hem directx hem de opengl apilerini geliştirmeyi öğrenirken bir yandan da uzay geometriyi ve bunun bilgisayar dünyasında uygulanışını iyi öğrenmelisin.



yok ben hobi amaçlı düşünüyorum. bi bakacam sadece belki sora ilerlemek isterim falan diyorsan, zaten yazılmış bir grafik motoru, yada oyun motoru kullanman en akıllıcası olur. çünkü büyük yazılım firmaları da oyun motoru geliştirmenin eziyetini çekmek yerine parayı verip ya geliştirilmişini alıyor. yada geliştirebilenlere geliştirtiyor. mesela dünyanın en iyi gerçek zamanlı grafik motoru teknolojilerini geliştirenlerin başında id software geliyor. onun dışında eagames ve benzer firmalar kendi oyunlarının motorunu kendileri yazarken, bir çok daha küçük firma geliştirilmiş bir oyun motorunu yada grafik motorunu satın alarak hiç o kısmına bulaşmayıp sadece oyunu ile ilgileniyor. sen de aynı stratejiyi uygulayabilirsin.

piyasada bir çok bedava oyun motoru var.                http://www.devmaster.net/engines/list.php?fid=21&sid=0
                                                                                                  kadir ilkimen

kayit.aspx (ASP.NET)

<%@ Page Language="VB" AutoEventWireup="false" CodeFile="kayit.aspx.vb" Inherits="kayit" %>

DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title>title>
head>
<body>
   
id="form1" runat="server">
    <div>
   
    div>
    <asp:CreateUserWizard ID="CreateUserWizard1" runat="server"
        CreateUserButtonText="Kaydı Tamamla"
        DuplicateEmailErrorMessage="E - mail adresin yanlış yalancı seniiii :)"
        DuplicateUserNameErrorMessage="Farklı bir kullanıcı adı gir  :)"
        UnknownErrorMessage="Hesabın oluşturulamadı  tekrar dene :)">
        <WizardSteps>
            <asp:CreateUserWizardStep runat="server">
                <ContentTemplate>
                    <table>
                       
                            <td align="center" colspan="2">
                                Yeni Hesap Oluşturtd>
                       
                       
                            <td align="right">
                                Kullanıcı Adı:td>
                            <td>
                                <asp:TextBox ID="UserName" runat="server">asp:TextBox>
                                <asp:RequiredFieldValidator ID="UserNameRequired" runat="server"
                                    ControlToValidate="UserName" ErrorMessage="User Name is required."
                                    ToolTip="User Name is required." ValidationGroup="CreateUserWizard1">*asp:RequiredFieldValidator>
                            td>
                       
                       
                            <td align="right">
                                Parola:td>
                            <td>
                                <asp:TextBox ID="Password" runat="server" TextMode="Password">asp:TextBox>
                                <asp:RequiredFieldValidator ID="PasswordRequired" runat="server"
                                    ControlToValidate="Password" ErrorMessage="Password is required."
                                    ToolTip="Password is required." ValidationGroup="CreateUserWizard1">*asp:RequiredFieldValidator>
                            td>
                       
                       
                            <td align="right">
                                Tekrar Parola:td>
                            <td>
                                <asp:TextBox ID="ConfirmPassword" runat="server" TextMode="Password">asp:TextBox>
                                <asp:RequiredFieldValidator ID="ConfirmPasswordRequired" runat="server"
                                    ControlToValidate="ConfirmPassword"
                                    ErrorMessage="Confirm Password is required."
                                    ToolTip="Confirm Password is required." ValidationGroup="CreateUserWizard1">*asp:RequiredFieldValidator>
                            td>
                       
                       
                            <td align="right">
                                <asp:Label ID="EmailLabel" runat="server" AssociatedControlID="Email">E-mail:asp:Label>
                            td>
                            <td>
                                <asp:TextBox ID="Email" runat="server">asp:TextBox>
                                <asp:RequiredFieldValidator ID="EmailRequired" runat="server"
                                    ControlToValidate="Email" ErrorMessage="E-mail is required."
                                    ToolTip="E-mail is required." ValidationGroup="CreateUserWizard1">*asp:RequiredFieldValidator>
                            td>
                       
                       
                            <td align="right">
                                Güvenli Soru:td>
                            <td>
                                <asp:TextBox ID="Question" runat="server">asp:TextBox>
                                <asp:RequiredFieldValidator ID="QuestionRequired" runat="server"
                                    ControlToValidate="Question" ErrorMessage="Security question is required."
                                    ToolTip="Security question is required." ValidationGroup="CreateUserWizard1">*asp:RequiredFieldValidator>
                            td>
                       
                       
                            <td align="right">
                                Güvenli Cevap:td>
                            <td>
                                <asp:TextBox ID="Answer" runat="server">asp:TextBox>
                                <asp:RequiredFieldValidator ID="AnswerRequired" runat="server"
                                    ControlToValidate="Answer" ErrorMessage="Security answer is required."
                                    ToolTip="Security answer is required." ValidationGroup="CreateUserWizard1">*asp:RequiredFieldValidator>
                            td>
                       
                       
                            <td align="center" colspan="2">
                                Parola İle Tekrar Parola Eşleşmelitd>
                       
                       
                            <td align="center" colspan="2" style="color:Red;">
                                <asp:Literal ID="ErrorMessage" runat="server" EnableViewState="False">asp:Literal>
                            td>
                       
                    table>
                ContentTemplate>
                <CustomNavigationTemplate>
                    <table border="0" cellspacing="5" style="width:100%;height:100%;">
                        align="right">
                            <td align="right" colspan="0">
                                <asp:Button ID="StepNextButton" runat="server" CommandName="MoveNext"
                                    Text="Kaydı Tamamla" ValidationGroup="CreateUserWizard1" />
                            td>
                       
                    table>
                CustomNavigationTemplate>
            asp:CreateUserWizardStep>
            <asp:CompleteWizardStep runat="server">
                <ContentTemplate>
                    <table>
                       
                            <td align="center" colspan="2">
                                Completetd>
                       
                       
                            <td>
                                Tebrikler ! Başarıyla Giriş Yaptınız !td>
                       
                       
                            <td align="right" colspan="2">
                                <asp:Button ID="ContinueButton" runat="server" CausesValidation="False"
                                    CommandName="Continue" Height="26px" Text="Continue"
                                    ValidationGroup="CreateUserWizard1" />
                            td>
                       
                    table>
                ContentTemplate>
            asp:CompleteWizardStep>
        WizardSteps>
    asp:CreateUserWizard>
   

body>
html>

asp.net

<%@ Page Language="VB" AutoEventWireup="false" CodeFile="kayit.aspx.vb" Inherits="kayit" %>
Yeni Hesap Oluştur
Kullanıcı Adı: *
Parola: *
Tekrar Parola: *
E-mail: *
Güvenli Soru: *
Güvenli Cevap: *
Parola İle Tekrar Parola Eşleşmeli
Complete
Tebrikler ! Başarıyla Giriş Yaptınız !

Monday, September 13, 2010

vhdl e düzgünce başlayalım artık


İşaret Dili

Çocukluğumda biraz öğrenmiştim ,fakat engelli deyip okullarını bile ayırdığımız ,sosyal yaşamdan soyutladığımız kardeşlerimizi görebilmek ne mümkün ,göremeyen yada işitemeyen kardeşlerimiz neden bizim sıralarımızda bizlerle birlikte oturmuyorlar? bizim, kardeşlerimizin işaret alfabesini öğrenebilmemiz çok kolayken ses ...kavramının ne olduğunu hissedemeyen kardeşlerimizden bizim alfabemizi öğrenmesini (okumasını yazmasını ve konuşmasını) istememiz nekadar acımasızca!!!!!!!!!!!!!!

Kendi Çalışmalarım

Kendi Çalışmalarım
2015

Kendi Çalışmalarım

Kendi Çalışmalarım
2015

Kendi Çalışmalarım

Kendi Çalışmalarım
2015

Kendi Çalışmalarım

Kendi Çalışmalarım
2011

Kendi Çalışmalarım

Kendi Çalışmalarım
2009

Kendi Çalışmalarım

Kendi Çalışmalarım
2007

Kendi Çalışmalarım

Kendi Çalışmalarım
2008

Kendi Çalışmalarım

Kendi Çalışmalarım
2015

Kendi Çalışmalarım

Kendi Çalışmalarım
2009