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.

    Ülke politikalarının belirlenmesinde yöneylem uygulamalarının büyük katkı potansiyeli vardır. Genel tecrübem iyi çalışmakta olan küçük&orta büyüklükte sistemlerde yöneylem uygulamalarıyla %10-30 arası iyileşme sağlanabildiğidir. Büyük sistemlerde bu iyileşme daha da büyük olmaktadır.

    Örneğin KDV’yi arttırıp vergi gelirlerini doğrudan arttırmaya çalışmak mı daha kârlıdır yoksa KDV’yi düşürüp vergileri dolaylı yoldan arttırmaya çalışmak mı daha doğrudur?
    Bu problem devlet çapında çok önemli bir optimizasyon problemidir.

    Bu noktada vergi oranındaki düşüşe paralel olarak toplanan vergilerin ne kadar artacağını bilmek gerekmektedir. İyi bir devlet yöneticisinden beklenen bu ikisi arasındaki ilişkiyi kurabilmektir.

    Örnek olarak Şekil 1’de vergi oranlarına göre oluşabilecek satış rakamları gösterilmiştir. Bu sanal örnekte vergiler %18’den ilk düşmeye başladığında ciddi bir artış görülmektedir ama düşüş arttıkça satışlardaki artış hızı (ivme) azalmaktadır.

    Vergi oranlarıyla ülkedeki genel satışlar arasındaki ilişki
    Şekil 1. Vergi oranlarıyla ülkedeki genel satışlar arasındaki ilişki

    Şekil 2’deyse bu durumda oluşan vergi gelirleri görülmektedir. Bu sanal örnekte %12 ve %13 KDV seviyelerinde devletin gelirleri 390.000 YTL seviyesine ulaşır. Oysa eğer vergiler %18′de bırakılsa şekil 1′de görüleceği gibi vergi geliri 180.000 YTL’de kalacaktı.

    Vergi oranlarıyla vergi geliri arasındaki ilişki
    Şekil 2. Vergi oranlarıyla vergi geliri arasındaki ilişki

    Problemin içine başka değişkenler de ekleyebilirdik:
    • Satışların artışıyla beraber ekonominin pozitif etkilenme durumu.
    • Düşük vergilerin etkisiyle vatandaşlardaki moral yükselmesi.
    • Düşük vergiler nedeniyle yurtdışından yatırımcıların Türkiye’yi yatırım için değerlendirmesi.

    Eğer bu 3 değişkeni de probleme ekleseydik o zaman problemi basit bir analizle çözmemiz mümkün olmayacaktı. Problem artık 4 değişkenli olacaktı ve bir yöneylem uzmanının yardımına ihtiyaç duyacaktık.

    Her ne kadar vergi alanında olmasa da benzer bir örnek geçtiğimiz hafta Kanada’da uygulamaya konuldu.

    Kanada hükümet’i düşen domuz ürünü fiyatlarının önüne geçmek için çiftçilere öldürdükleri domuz başına $225 vereceğini açıkladı. Bu proje için 50 milyon dolar ayrılmış durumda. Proje bittiğinde ülkedeki domuzların %10′unun öldürülmüş olması bekleniyor. Bu sayede domuz ürünlerinin fiyatlarının tekrar yükselmesi ve sektördeki dengenin geri gelmesi hedefleniyor. Bu çalışmanın hassas bir yöneylem çalışmasının ürünü olduğu çok açık. Proje işe yararsa sanırım Kanada’da yöneylem uygulamalarının sayısının artması beklenebilir.

    Adobe Air Logo
    Son on yıla damgasını vuran yazılım firmaları arasında Adobe’u da sayabiliriz şüphesiz. Hatta bilgi işlem piyasasındaki pek çok firma birbirleriyle mahkemelerde uğraşırken Adobe’un sadece çıkardığı muhteşem ürünlere konsantre olduğunu da söyleyebiliriz.

    İşte Adobe yine böyle muhteşem bir ürünün hazırlığını bitirmek üzere. Biliyorsunuz Java ve .net tabanlı yazılımlarının çalışması için bilgisayarınızda dönüştürücülerin hazır olması gerekiyor. İşte Adobe da böyle dönüştürücülü bir yazılım altyapısının hazırlığı içinde: “Adobe AIR“.

    Eğer yazılım konusunda deneyiminiz varsa bilirsiniz ki ne java, ne .net ne de c++ görsel ve kullanışlı bir ortam hazırlama konusunda HTML, Flash ve Ajax’taki rahatlığı ve sürati sağlamaz. İşte Adobe AIR tam bu noktada devreye giriyor ve aslında web teknolojileri olarak kullanılan HTML, Flash ve Ajax’ı birleştirerek masaüstü için yazılımlar hazırlamanızı sağlıyor. Yani çok hızlı bir şekilde kullanışlı ve görsel açıdan güzel yazılımlar hazırlamanıza imkan sağlıyor.

    Adobe AIR klasik yazılım yapılarından farklı olduğu için muhtemelen yazılım camiasında ilk başta sıcak karşılanmayacaktır. Ancak zaman içinde vazgeçilmez bir yazılım altyapısı olmaya aday olduğu kesin. Ayrıca getirdiği yenilikler düşünüldüğünde .net’ten ve c++’dan masaüstü alanında ciddi pazar payı çalmaması için bir sebep de göremiyorum. Java’dansa pazar payı çalabileceğini sanmıyorum çünkü Java zaten burada ayrıntısına girmek istemediğim pek çok sebepten ötürü masaüstü pazarında marjinalleşmiş ve sadece fanatiklerinin kullandığı bir programlama dili.

    Adobe, AIR’i 2008′in bahar aylarında piyasaya sürmeyi planlıyor.

    Daha eski yazılar »