Bir gün “sadık bir IBM müşterisi” olacağım aklıma gelmezdi ama oldum.

Bunun sorumlusu ben miyim değil miyim bilmiyorum. Dahası iyi mi oldu kötü mü oldu onu da bilmiyorum.

Herşey bundan bir yıl önce o dönemde çalıştığım internet sitesininin veritabanıyla uğraşmamla başladı. Nasıl olduysa, eskiden sadece bankaların tercih ettiği DB2 (IBM’in veritabanı sistemi) popüler bir internet sitesinin veritabanı olmayı başarmıştı. Internet sitelerinde genelde Oracle, MSSQL ya da MYSQL tercih edilirken DB2 bizim şirketin kapısından içeri girmeyi başarmıştı. Velhasıl, ben de duruma ayak uydurup kalın kalın kitaplardan DB2 öğrendim.

Ben daha DB2′yu öğreniyorum derken, IBM ILOG‘u satın aldı. ILOG, CPLEX‘in sahibi olan Fransız firması. CPLEX de en fazla satılan yöneylem yazılımı. Ayrıca doktoramın bütün deneylerinde de kullandığım yazılım. Yani CPLEX ile aramızdaki bağ daha uzun yıllar sürecek ve ben yıllarca IBM müşterisi olacağım.

Derken geçen hafta SPSS‘ten bir e-posta aldım. IBM SPSS‘i de satın almış. SPSS malum istatistik konusunda en çok satılan birkaç yazılımdan biri. SPSS’in Clementine isimli veri madenciliği yazılımıysa veri madenciliği konusunda en önde giden yazılım paketlerinden biri. SPSS’i de önümüzdeki yıllarda sıkça kullanacağım aşikar.

Yani kısacası artık sadık bir IBM müşterisiyim. Yıllarca “negatif” imajını her yerde gördüğüm ama bir türlü hiçbir ürünü ilgi alanıma girmediği için önem vermediğim IBM artık üç temel ürünüyle kullanımımda.

Özellikle son CPLEX ve SPSS satın almaları benim açımdan çok önemli. Bu iki yazılım kendi başlarına piyasada önemli gelişmeler sağlamış, pek çok deneyi, araştırmayı mümkün kılmış yazılımlar. IBM’in kurumsal yapısına girdiklerinde dinamizmlerini koruyabilecekler mi? Yoksa SAP gibi kullanımı, kurulumu zor, ve hatta kullanabilmek için bir “danışman ordusunu” çalıştırmayı zaruri kılan yazılımlar mı olacaklar? İsteğim tabi ki IBM’in finansal kuvvetini, müşteri portföyünü kullanarak bu yazılımların kendilerini geliştirmeleri ama doğrusu o ya ümidim pek az.

Yöneylem problemlerini çözmek için heuristiclere sıkça başvurulur. Heuristic kodlarında performans denetimi oldukça önemlidir. İyi bir denetlemeyle kodun süresel performansını 10 ila 100 kat, hatta bazen daha bile fazla arttırmak mümkün olacaktır. Bu gibi denetleme işlemlerini yapmak için kullanılan yazılımlara “profiler” denir.

Java’da yazdığım bazı heuristicleri denetlemek için geçtiğimiz hafta YourKit isimli java profiler‘ı kullanmaya başladım. YourKit sayesinde kodlarımda tahmin etmeyeceğim yerlerde darboğazlar buldum ve bu darboğazları giderince süresel performansta büyük artış oldu.

YourKit’in özellikle üç özelliği fazlasıyla önemli:
1. Eclipse ile entegre çalışıyor
2. CPU süresinde method bazlı profiling yapıyor
3. Hafıza kullanımını ayrıntılı olarak denetliyor

Eclipse ile entegrasyonu aşağıdaki şekilde görebilirsiniz. Tıpkı debug ya da normal run yapar gibi profiling yapmaya başlayabiliyoruz. Zaten hali hazırda ayarlamış olduğumuz run configurasyonlarımız otomatik olarak profiling’e hazır bekliyorlar.

YourKit eclipse integration

Aşağıdaki şekil YourKit’in hafıza profiling ekranından bir kesit gösteriyor. Kırmızı çizgi o anda Java Virtual Machine’de bize ayrılan toplam hafızayı gösteriyor.
Mavi çizgiyse anlık olarak kullandığımız hafızayı gösteriyor. Limit olarak yazan 1.6GB Java Virtual Machine’e maximum heap size olarak belirttiğimiz hafıza.
Eğer yazılımınızda heap memory’yi aştığınıza dair hata alıyorsanız bu ekran genel olarak hafıza kullanımınızı takip etmek için bire bir.

YourKit memory usage

Son ama bir diğer çok önemli özellik de CPU profiling. CPU’nun ne zaman ne kadarını kullandığımızı bu özellik sayesinde görüyoruz. Hangi metodun ne kadar süre harcadığını, CPU’nun yüzde kaçının kullanıldığını bu ekranda görüyoruz.

YourKit eclipse cpu usage

Fiyatı da çok yüksek sayılmaz. Bütün üniversitede geçerli olacak akademik lisansları sadece 999$’a satıyorlar. Tekil lisanslar 135$ dolarla öğrenci bütçesine pek uygun değil şüphesiz ama fonu olan araştırma projelerinde çok da büyük bir maliyet sayılmaz.

Özet olarak java profiler gerçekten çok faydalı bir ürün. Özellikle heuristic kodlayan yöneylemciler için gerçekten çok faydalı. Ayrıca sadece java değil .net profiling özelliği de var.

Yöneylem Konferansı
Michael Trick‘in blog’unda çok enteresan bir resime link verilmiş. 1957 yılında Oxford’da düzenlenmiş olan dünyanın ilk yöneylem araştırması konferansının anı fotoğrafı. Fotoğrafta George Dantzig dahil pek çok yöneylem efsanesi yer alıyor.

ILOG logo
IBM, önde gelen yöneylem araştırması yazılımlarından CPLEX’in sahibi ILOG’u satın almak için görüşmelere başladığını duyurdu.
Michael Trick’in de kendi blog’unda ayrıntılı olarak yer verdiği gelişme yöneylem araştırması açısından büyük önem taşıyor. Internetnews.com’da da bu satın alma haberiyle ilgili bir analiz okuyabilirsiniz.

IBM, 2000 yılından bu yana açık-kaynak bir yöneylem projesi olan COIN-OR‘ı destekliyordu. Ancak bu yazılımı şu ana kadar ticari bir yapıya sokmamışlardı. ILOG’u satın aldıklarında da CPLEX ile COIN-OR’ı muhtemelen birbirinden ayrı projeler olarak tutmaya devam edeceklerdir.

Bu satın alma gerçekleşirse ilk kez büyük çapta bir firma doğrudan yöneylem araştırması hizmeti vermeye başlamış olacak ki bu yöneylem dünyası için çok iyi bir gelişme. Bu durumda önümüzdeki dönemde IBM’den simülasyon alanında bir satın alma da şaşırtıcı olmaz.

Yazılımcıların da endüstri mühendislerinin de en büyük ihtiyaçlarının başında “ortak modelleme dili” ihtiyacı gelir. UML‘in (Unified Modeling Language) Kasım 1997′de OMG tarafından yayınlanmasıyla birlikte yazılımcıların ihtiyaçları büyük ölçüde karşılanmıştı. UML sayesinde yazılımcılar artık sadece diyagramlar aracılığıyla birbirlerine fikirlerini anlatabiliyorlar, yazılım tasarımı yapabiliyorlardı. Hatta daha da önemlisi, bütün süreçler şekiller üzerinde olduğu için yazılımı diğer departmanlara da daha iyi tanıtabiliyorlardı (Örneğin: Pazarlama, reklam, görsel tasarım, yönetim, vb…).

UML’in çıkışıyla beraber pek çok endüstri mühendisi de UML’i modellerinde kullanmaya başladı. Simülasyon olsun, yöneylem modeli olsun her çeşit modellenebilecek sistem için UML kullanmaya başladık. Fakat aslında, UML, endüstri mühendislerinin ihtiyaçlarını yeterince karşılayamıyordu. UML’in temel olarak yazılım için tasarlandığı pek çok aşamada belli oluyordu.

Eylül 2007′de v1.0′ı yayınlanan SysML (Systems Modeling Language) sayesinde endüstri mühendislerinin de ihtiyacı karşılanmış oldu.

SysML v1.0 ile UML 2 arasındaki ilişki genel olarak aşağıdaki şekilde gösterildiği gibidir.

Systems Modeling Language vs Unified Modeling Language

    Şekil 1. SysML v1.0 ile UML 2 arasındaki ilişki. Kaynak: http://www.omgsysml.org/

Şekilde görüleceği gibi, SysML, UML 2′deki bazı özellikleri aynen kullanıyor, bazılarını kullanmıyor ve bazı yeni özellikler ekliyor.

Eklediği diyagramlar arasında en önemlilerden biri “requirements” diyagramı. Bu diyagram sayesinde tasarlanan sistemin ihtiyaçlarını dökümana dökmek kolaylaşıyor. SysML’in bir diğer önemli özelliğiyse sisteme “donanım”, “yazılım”, “bilgi”,”personel”, “prosedür”, “tesis” gibi unsurların da dahil edilmesi.

SysML üzerine şu an amazon’da sadece bir kaç tane kitap bulmak mümkün. SysML’in yeni versiyonu v1.1 şu an onay aşamasında. Bu onay işleminden sonra piyasadaki kitap sayısının artması beklenebilir.

SysML’i yakından tanımak isteyenler için şu adresteki tutorial iyi bir kaynak olabilir. Daha teknik bilgi arayanlarsa doğrudan teknik dökümanını okuyabilirler.

Projelerin standart bir dille tasarlanması endüstri mühendisliği projelerinin kalitesini gözle görülür şekilde arttıracaktır.

Akademik makaleler çok fazla terim ve ispat içerirler. Ortalama bir makale 20-25 sayfayı geçmese de okuması ve anlaması çoğu zaman en az 3-4 saati bulur, hatta bazen günler sürebilir. Dolayısıyla bir akademik makalenin nasıl okunması gerektiği verimlilik açısından çok önemlidir. Bundan 4-5 yıl önce iki hocamın (Dr. Armacost, Dr. Pet Armacost) bu konuda verdikleri bazı tavsiyeleri burada yazmak istiyorum.

Makale okumaya abstract’le başlanmalıdır. Abstract’ten önce makaleye kısaca göz atılabilir, hatta eğer kısaysa “sonuç” bölümüne de bakılabilir. Ancak genel kural önce abstract’in okunmasıdır.

Abstract’i okuyunca eğer halen makalenin ilgimizi çektiğini düşünüyorsak o zaman hemen ardından “sonuç” bölümünü okumakta fayda vardır. Eğer sonuçlar da ilgimizi çekmişse o zaman “giriş”i okumak gerekir.

Abstract, “sonuç” ve “giriş” bölümlerini okuduğumuzda artık makalede ne anlatıldığında dair somut bir fikrimiz olur. Üstelik bu bölümlerin dili genelde daha basit olduğundan vakit kaybımız az olacaktır.

Eğer halen makalenin bizim için önemli olduğunu düşünüyorsak o zaman metodolojiyi (ispatlar vb.) ve deneyleri okuyabiliriz. İşte bu bölüm vakit ayırmamız ve dikkatli okumamız gereken bölümdür. Buradaki ispatları iyi anlamak ileride yazacağımız tez ve makaleler açısından büyük önem taşır.

Pek çok makalenin içinde yer alan “literatür taraması”nı okumaksa sizin insiyatifinize kalmıştır. Çoğu zaman makaleyi anlamak için literatür taramasını okumak gerekmez. Konu hakkında çok uzmansanız sadece bir göz gezdirmeniz yetecektir. Eğer bu alanda başka araştırma yapmayacaksanız okumanıza bile gerek olmayabilir. Literatür taramasını okuyacaksanız bile en sona bırakmanızda sakınca olmaz.

Yani özetlersek şu sırayı tavsiye edebiliriz: Abstract –> Sonuç –> Giriş –> Metodoloji & Deneyler –> Literatür taraması

Bu yazıda Milli Takım’ın 1923′ten bugüne gösterdiği performansı ELO yöntemiyle inceleyeceğiz ve gelecekteki performansını öngörmeye çalışacağız.


Türk Milli Takımı'nın ELO sıralaması

    Şekil 1. Türk Milli Takımı’nın ELO puanlamasına göre 1923′ten bugüne sıralaması. (Tıklayıp büyük olarak görebilirsiniz)

Şekil 1′de Milli Takım’ın 1923′ten bu yana ELO yöntemine göre dünya futbolundaki sıralamasını görüyoruz. ELO yöntemi kısaca şöyle çalışır: Dünya’daki her milli takımın kendine ait bir ELO puanı vardır. Yapılan her müsabaka sonunda kazanan takım ELO puanları alır, kaybeden takım da ELO puanları kaybeder. Kazanılan ve kaybedilen ELO puanları maçın skoruna göre değişir. Kuvvetli bir takım zayıf bir takımı yenerse az ELO puanı kazanır, mağlup takım da az ELO puanı kaybeder. Şekil 1′de görülen ELO puanına göre sıralamalar eloratings.net’ten alınmıştır.

Kısaca ELO’yu tanıdıktan sonra Şekil 2′de Türkiye’nin hem siyasal hem futbol tarihindeki önemli noktalarının ELO sıralamamız üzerindeki yerlerini görüyoruz.


Türk Milli Takımı'nın tarihindeki önemli noktalar

    Şekil 2. Türk Milli Takımı’nın tarihindeki önemli noktalar (Tıklayıp büyük olarak görebilirsiniz)

Göreceğiniz gibi, Milli Takım’ın 1923 Ekim’inde başlayan serüveni ilk zamanlarında pek başarılı gitmiyor. Bundaki en temel etkenler:

    -Atatürk’ün ölümü
    -İkinci Dünya Savaşı
    -Finansal problemler

Takımın bu problemleri atlatıp belli bir istikrara ulaşması 1950′leri buluyor. 27 Mayıs İhtilali’nin takım üzerinde ilk başta pek negatif etkisi olmasa da demokrasiye tekrar geçilmesinin ardından bir düşüş dönemine giriliyor, ta ki Tınaz Tırpan takımın başına geçene kadar (Futbol Federasyonu’nun web sitesinde Milli Takım’ın bütün maçlarıyla ilgili detayları bulmak mümkün).

Yaptığımız analiz objektif olarak gösteriyor ki Milli Takım’ın ilk yükselişi Tınaz Tırpan döneminde gerçekleşiyor. Hatta Tınaz Tırpan yönetiminde Milli Takım 1990 Dünya Kupası’na katılma şansını grup elemelerinde son maça kadar getiriyor. 15 Kasım 1989′da grup elemelerindeki son maçta Simferopol’de Milli Takım Sovyetler’e 2-0 yeniliyor ve İtalya’ya gitme hakkını elinden kaçırıyor.

Yukarıdaki verilere bakıldığında takımda aslında teknik direktörlerden bağımsız bir yükseliş olduğu görülüyor. Son 20 yıl içinde Sepp Piontek dışındaki bütün teknik direktörler takımı ya daha iyiye götürmüşler ya da performansı korumayı başarmışlar. Buradaki tek sıradışı teknik direktör Ersun Yanal, ancak onun da takımın başında geçirdiği sürenin kısalığı dikkat çekiyor. Şekil 2′ye dikkatli bakılırsa Ersun Yanal dönemindeki düşüşten daha büyüğünün Mustafa Denizli yönetiminde de yaşandığı görülür. Dolayısıyla Ersun Yanal döneminde yaşanan düşüşün aslında adaptasyona dayalı geçici bir düşüş olma ihtmali var.

Takımın başarısının teknik direktörlere çok da bağlı olmadığı görülünce takımın performansının arkasındaki asıl etkeni başka bir yerde aramak gereği ortaya çıkıyor. Şekil 3′te bugüne kadar yapılan canlı yayın ihalelerinde elde edilen yıllık gelirler görülmektedir. Gelir rakamları Serdar Ali Çelikler’in şu yazısından derlenmiştir.

Canlı yayın ihalelerine göre yıllık gelirler

    Şekil 3. TFF canlı yayın ihalelerine göre yıllık gelirler (Tıklayıp büyük olarak görebilirsiniz)

Federasyon’un canlı yayın gelirlerinin her artışından 2-3 yıl sonra Milli Takım’ın ya sıralamasında artış olduğu ya da önemli bir başarı elde edildiği net olarak görülüyor. Yani kulüp takımların yıllık bütçeleri canlı yayın gelirleri sayesinde artıyor ve bu artışla beraber ligin kalitesi de zamanla yükseliyor. Dolayısıyla da Milli Takım daha başarılı oluyor.

Son analizimizi de yine grafik üzerinden yapıyoruz ve Milli Takım’ın Dünya futbolunda üst sıralara gelme ihtimalini şekil 4′te öngörmeye çalışıyoruz.


Milli Takım'ın performansının projeksiyonu

    Şekil 4. Milli Takım’ın performansının grafik analizle projeksiyonu (Tıklayıp büyük olarak görebilirsiniz)

Şekil 4′te Milli Takımın performansının Tınaz Tırpan’la başlayan dönemden bugüne alt ve üst sınırlarını kapsayan bir koridor çizip bu koridoru geleceğe doğru uzatıyoruz. Bu analizde sadece Sepp Piontek’le dip yaptığımız bir dönemi sıradışı (“Outlier”) kabul edip analize dahil etmiyoruz. Grafik analiz’de gözüken o ki Milli Takım 2013 civarında Dünya’nın en iyi takımları arasına girme potansiyelini taşıyor. 2012′de Polonya-Ukrayna Avrupa Şampiyonası’nda en azından yine yarı final oynanması çok muhtemel. Ardından da 2014′te Brezilya Dünya Kupası’nda da final oynama şansı oldukça yüksek.

ELO’nun matematiksel formüllerini temel alan bu kısa analizin sonuçlarını şu şekilde özetleyebiliriz:

    -Milli Takım’ın performansında canlı yayın ihalelerinin büyük etkisi var.
    -2010 canlı yayın ihalesi Milli Takım’ın geleceği açısından çok önemli.
    -2014 Brezilya Dünya Kupası’nda Milli Takım’ın büyük şansı var.

MIT’nin prestijli “teknoloji” dergisi Technology Review Aralık 2005′te “The Internet is Broken” (“Internet bozuk”) isimli bir makale yayınladı. Bu makale o dönem pek çok gazete haberine konu oldu. Internet’in ne kadar güvensiz olduğu pek çok yerde tartışıldı ama bugüne kadar geliştirilen tedbirlerin hiçbiri yeterli olmadı.

Kısaca konunun özünü hatırlarsak: Internet’te ilettiğiniz bilgiler normalde güvensiz hatlar üzerinden gider gelir. Yani telefon hattınız dinlemeye alınsa bilgisayarınızla Internet arasındaki bütün iletişim izlenebilir ve yaptığınız bütün yazışmalar okunabilir, gönderdiğiniz/baktığınız bütün resimler görülebilir.

Tabi yukarıdaki problem sadece normal iletişimde söz konusu, e-ticaret siteleri ve benzeri sitelerle yaptığınız işlemlerde böyle bir sorun yok çünkü bu iletişim sürekli şifrelenir. Dolayısıyla bilgisayarınızla e-ticaret sitesi arasında yapılabilecek bir dinlemede siteye yolladığınız bilgilerin deşifre edilmeden okunması mümkün olmaz. Bu deşifre işlemi de teori’de 100′lerce asır alır.

Bu yazıdaki konumuz şifrelenmeyen normal Internet iletişimi. Pirate Bay bu probleme ciddi bir çözüm önerisi sunmaya karar vermiş ve Temmuz başında yeni bir standart önerisinde bulunmuş: IPETEE . Bu standartın amacı kullanıcıların bilgisayarlarına yükleyecekleri ufak ve standartlara uygun yazılımlar sayesinde bilgisayarlar arasında gidip gelen verilerin şifrelenmesi.

Eğer bu standart genel kabul görürse artık bilgisayarınızdan yolladığınız verilerin başkaları tarafından okunma olasılığı gerçekten düşük olacak. Tabi böyle bir şifreleme doğrudan TCP/IP seviyesinde yapılacak bir şifreleme kadar düşük izli olamaz ama yine de aplikasyon seviyesine gelmeden uygulanması planladığı için etkili olacaktır.

Tabi bu konunun semantik web’e de dolaylı fakat önemli bir etkisi var. Güvenli bir internet demek pek çok firmanın sunucularını internete daha güvenle açması ve paylaştığı veriyi görece daha fazla yapabilmesi demek.

Google
Semantik web dönemine geçişimizdeki en önemli aşama dünya üzerindeki sunucuların insan yardımına ihtiyaç duymadan birbirleriyle konuşabilmesi olacak. İki serverı birbiriyle konuşturmak şüphesiz basit bir iş, ancak semantik web’deki amacın dünya üzerindeki bütün sunucuların hatta client’ların birbirleriyle konuşabilmesi olduğunu düşünürsek bütün bilgisayarların ortak bir dile sahip olması çok önemli bir adım.

Semantik web’in dayandığı en önemli ortak dil alt yapısı SOAP‘tu. SOAP standartlarını kullanan iki sunucu birbirleriyle XML standartlarını kullanarak yazışabiliyorlar (Veri alıp verebiliyorlar). Hatta eğer iki sunucu da yazışmada kullanılan ontolojileri biliyorsa o zaman problemsiz olarak birbirlerini de anlayabiliyorlar.

SOAP’un formatını belirleyen teknik XML’inse çok yer kaplamak ve uzun sürede oluşturulmak (parse) gibi dezavantajları var. Sonuçta XML’lerin her ne kadar kolay anlaşılır text yapıları olsa da transfer edilen verilerin büyüklüğü sunuculara ve iletişim ağlarına yük olabiliyor. Dolayısıyla pek çok büyük firma kendi serverları arasında iletişimi sağlarken SOAP yerine, daha az yer tutan ve hazırlanması daha az zaman alan sistemler geliştirir. Bu geliştirdikleri sistemler sayesinde sahip oldukları binlerce sunucu kendi aralarında problemsiz konuşabilirler. Ancak bu sunucular internetteki diğer bilgisayarlarla bu dili kullanarak haberleşemezler.

Bugüne kadar, en azından benim bildiğim kadarıyla, SOAP’a alternatif olabilecek bir standart yoktu. Google şimdi böyle bir standart önerisinde bulunuyor, Protocol Buffers. Detaylarını da bu sayfalarda anlatmışlar. Örneğin XML’le 69 byte tutan veriyi Protocol buffers kullanarak 28 byte’ta kaydedebildiklerini yazmışlar. Ayrıca bu bilgilerin XML olarak hazırlanması (parse) 5,000-10,000 nanosaniye sürerken Protocol Buffers’a uygun olarak hazırlanması 100-200 nanosaniye alıyormuş.

Google’ın kendisi için geliştirdiği bu ufak sistemi bütün dünyayla paylaşıp faydalı bir standart yaratmaya çalışması gerçekten takdirlik bir davranış. Semantik web yolunda önemli bir adım.

Python logo

Yöneylem üzerine uzmanlaşan pek çok araştırmacı geliştirdiği algoritmaları bilgisayar ortamında kodladıkları deneylerle test eder.
Bu deneyler çoğu zaman farklı parametreleri içerecek şekilde yapılır. Örneğin, bir lineer programlama deneyinde “amaç fonksiyonu”nu farklı yapılarda incelemek istenebilir. Bu durumda her yeni yapı için deneyin baştan tekrarlanması gerekmektedir. Bu tip bir deneyi peşpeşe yapmak için birkaç farklı teknik vardır. Bunlardan özellikle iki tanesi sıkça kullanılır:

  • Her seferinde deney yazılımını baştan çalıştırmak: Her deney bittiğinde, araştırmacı, kodu tekrar düzenler (yeniden compile eder) ve tekrar çalıştırır. Ya da benzer bir uygulama olarak deney bittiğinde exe’ye yeni parametreleri verip yeniden deneyi başlatırlar(Örneğin: “c:/deney.exe -parametre:a”, “c:/deney.exe -parametre:b” gibi).
  • Döngü yardımıyla deneylerin gerçekleştirilmesi: Kodun içine farklı parametreler yazılır ve bir çeşit “for to” döngüsü kullanılarak deneylerin peşpeşe yapılması sağlanır.
  • İki yöntemin de önemli dezavantajları var.
    Birinci yöntemde kodun transfer edilebilmesi ve paylaşılabilmesi çok kolaydır ama her deney bittiğinde bilgisayar başında olmak gerekmesi kaynak ısrafı yaratır.
    İkinci yöntemdeyse kodun transfer edilebilmesi zorlaşmaktadır. Diyelim ki ilk deneyden iki yıl sonra deneyi baştan yapmak isterseniz tekrar kodun içine girmeniz gerekecektir. Kodun içine yazdığınız döngüleri hatırlamanız ve üzerinde modifikasyon yapmanız gerekecektir. Üstelik kaynak kodu ve compiler’ı saklamanız gerekmesi de ek bir problemdir.

    Bu durumda alternatif bir metod olarak script tipindeki programlama dilleri kullanılabilir. Deneyler scriptler yardımıyla çalıştırıldığında hem deneylerinizin peşpeşe otomatik olarak çalışmasını sağlamış olursunuz hem de deney kodunuzun için parametrelerinizi yazmanız gerekmez.

    İşte bu programlama dilleri arasında en kullanışlı olanlarından biri Python‘dur. Phyton’u indirmek için şu adrese gidip önce “The current product version” linkine tıklamanız gerekiyor. Bir sonraki ekranda hangi işletim sistemini kullandığınızı seçmelisiniz. Eğer sıradan bir Windows’unuz varsa “x86″ versiyonunu indirip kurabilirsiniz.

    Kurulum bitince Python’u hemen çalıştırabilirsiniz. Açılan konsol’da doğrudan Python komutları vermeniz mümkün. Python kodlamaya başlamak için şu dökümanı inceleyebilirsiniz. Örneğin şu tip bir komutla yöneylem deneyinizi çağırabilirsiniz: os.system(“c:\deney.exe 10 20″) Bu örnek kod C’deki deney.exe’yi 10 ve 20 parametreleriyle çağıracaktır.

    Diyelim ki 10 parametresini değiştirmek istiyorsunuz ve 10,11,12,13,14,15 olacak şekilde peşpeşe 6 deney yapmak istiyorsunuz, bu durumda range() veya for() döngüleriyle istediğiniz kadar deneyi peşpeşe çağırmanız mümkün olacaktır.

    Python’u istediğiniz gibi kullanmayı öğrenmeniz muhtemelen 1 saatinizi almayacaktır ve kodunuzu temiz tutmanızı sağlayacağı için de size büyük zaman kazandıracaktır.

    Daha eski yazılar »