Yazılımcı pazarı

05 March 12, Monday @ 15:32

Yazılım geliştirici olarak iş aramak garip biçimde hem çok kolaylaşıyor hem de çok zorlaşıyor. Zorlaşmasının nedeni gereken bilgi ve deneyim seviyesinin sürekli artması. Kolaylaşmasının nedeni ise şirketlerin yazılımcı ihtiyacının bu seviyeden daha hızlı biçimde yükselmesi.

Mesela Amerika gibi güçlü CS (Computer Science, Bilgisayar Bilimleri) bölümlerine sahip üniversitelerin olduğu ve bir yandan da yurtdışından yazılımcı ithal eden bir ülkede, iyi bir yazılımcı bulup işe almak beklenmedik kadar güç bir iş. İlk önce verdikleri astronomik rakamlarla Wall Street ve keyifli ortamıyla üniversiteler bu kitlenin kaymağını topluyor, daha sonra da Google, Apple, Microsoft, Facebook, vb gibi isim sahibi firmalar. Kalanları kapabilmek için de küçük startuplar daha "cool" olma ve gelecekte dünyayı ele geçirme umutları satmakta birbirleriyle yarışmaktalar.

Bu kıran kırana ortamın iş ve işçi arayışını hallice değiştirmiş olması şaşırtıcı değil.

İşverenler başvuru beklemek yerine iyi geliştiricilerin takıldığı ortamlarda araştırma yapıp buldukları potansiyel adaylara görüşme teklifi gönderiyorlar. Büyük çaplı olanlar üniversitelere yerleşip potansiyel sahibi öğrencilerden stajyer kapmaya çalışıyor. Araştırma ortamlarından birisi diğer geliştiricilerin sosyal ağları. LinkedIn gibi profesyonel sosyal ağ siteleri, StackOverflow, TopCoder gibi bilgi paylaşımı ve yarışmalar yapılan siteler, özgür yazılım projelerine ev sahipliği yapan GitHub, GoogleCode gibi siteler belli başlı kaynaklar.

Ancak kendinizi görünür kılmanın en kolay ve etkili yolu bir özgür yazılım projesine katkıda bulunmak. Bu konuda geçen sene başında Javascript'çilerin ismini tanıyacağı bir geliştirici, John Resig İşe alma söz konusu olduğunda, bir Github commit'ini herhangi bir CV'ye tercih ederim diye bir laf etmişti ve epey tartışma yaratmıştı. Bu kapalı kod üreten işlerde çalışanların çok işine gelen bir durum değil. Bir şirkette onbeş yıl çalıştıktan sonra elinizde başkalarına göstermeye izniniz olan herhangi bir örnek kodunuz olmayabilir. Ancak eşitsiz ve acımasız da olsa gidişat bu yönde, çünkü birisinin yazılım becerisini değerlendirmenin en kolay ve hızlı yolu yazdığı koda bakmak. Özgür yazılım projelerinde kişinin test ve belge üretme, diğer geliştiricilerle ve kullanıcılarla birlikte çalışma gibi çok daha önemli özellikleri de bir ayna gibi görülebiliyor.

Tabii ki her projenin görünürlüğü farklı derecede. İş ilanlarından güncel bir derleme yaparsak, mesela Nginx, haproxy, Hadoop, memcache, Redis, MongoDB, puppet, vb gibi özgür yazılımlar epey sık geçiyor. Dolayısıyla bunlar üzerindeki deneyim ve katkılarınız daha çok ilgi çekme şansına sahip. Yazılımların sayfalarında yada şirketlerin mesela performansla ilgili sunumlarında neler kullandıklarını daha yakından görebilirsiniz.

Bir şekilde bağlantıya geçtikten sonraki adım ön eleme. Burada genelde daha önce yaptığınız işler, şirketin neler yaptığı, işin ilginizi çekip çekmediği gibi daha klasik konular konuşulmakta ve mesela şirketin yazılımcılarından biriyle kısa süreli bir telefon görüşmesi yapıp teknik bilginiz değerlendirilmekteydi. Ancak son zamanlarda arttığını gördüğüm bir uygulama daha var. Size bir problem ve bu problemi çözmek için yazılmaya başlanmış bir program gönderiyorlar, birkaç saat içinde programın hatalarını ayıklayıp, yeni özellikler ekleyip, belki bazı kısımları daha düzgün şekilde yeniden yapılandırıp geri gönderiyorsunuz. Programın çalışması kolayca test edilebileceği için şirketin yazılımcılarının incelemesinden önce epey bir eleme yapılabiliyor.

Asıl görüşme kısmı ise neredeyse tamamen Google modeline dönmüş durumda. Yarım gün falan süren, tamamen teknik konulardan oluşan ve tahtada kod yazılan zorlu bir sınav. Ağaç ve graph yapıları, arama ve sıralama, karmaşıklık gibi teorik konular, bildiğiniz programlama dilinin en ince detayları, işletim sistemi, ağ ve bilgisayar mimarisi. Bazı firmalar bu konsepti yalnızca gördükleri kadarıyla taklit ettikleri için, anlamsız derecede zor yada adaletsiz sorular sorabilirler. Bazı firmalar ise üniversite CS eğitiminin üzerinde ve gerçekten etkileyici yanıtlar bekleyebilir. Burada başarılı olmak için günceli takip etmek gerekiyor. Bildiğiniz sıralama algoritmaları Quick, merge ve heapsort'tan ibaret olmasın. Ağaç deyince aklınıza binary tree değil, Suffix tree, R tree, Radix tree, Judy array falan gelsin.

Bu konuları öğrenecek bir dolu kaynak var internette. Mesela AI Class, Udacity ve ML Class özellikle istatistiksel yöntemler ve yapay zeka konusunda çok başarılı kaynaklar. Bir diğer yardımcı da yine özgür yazılımlar. Favori yazılımlarınızın hangi algoritmaları kullandığına baktınız mı hiç? Mesela bellekte bir kopyalama işlemini nasıl en hızlı yaparsınız? eğer glibc kodunu açıp memcpy fonksiyonuna baktıysanız cevabı görmüşsünüzdür :) Ya da mesela onbinlerce bağlantıyı aynı anda yönetebilen bir sunucu nasıl yazılır? Nginx, lighttpd ve Apache gibi özgür yazılımların içinde buna dair ipuçları olsa gerek değil mi?

Bütün bu tantana yalnızca almışken daha iyi elemanı alalım kaygısından ya da beğenilen bir şirkete girmeye çalışmaktan kaynaklanmıyor. Gelişen teknoloji ve artan kullanıcı sayısıyla birlikte işlenen veri inanılmaz boyutlara ulaştı ve bu veriden çıkarılacak anlamlı sonuçlara, en başta reklam sektörü tarafından, çok büyük paralar ödeniyor. Dolayısıyla daha hızlı, daha az kaynak kullanan, daha başarılı sonuç üreten ürünler aslan payını kapıyor. Burada rekabet hem algoritma seviyesinde, hem de o algoritmayı en ideal biçimde gerçekleyeceğiniz uygulama seviyesinde.

Bu düzeye yalnızca dört senelik üniversite eğitimiyle (hele hele ar-ge yapılmayan ve seviyesi düşük üniversitelerde) ya da hobi seviyesinde bir programcılık ilgisiyle gelmek mümkün değil. Mutlaka zorlu problemlerle karşılaşıp bunlara çözümler geliştirmeniz, bir yandan da teorik bilgilerinizi sağlamlaştırmanız lazım.

Böyle bir hedefiniz varsa, stajınızı, çalışacağınız şirketleri, yapacağınız kişisel projeleri dikkatle seçmeniz gerekli. Mesela yüksek maaşlı ancak rutin ve yıpratıcı bir işe girip, uzun bir süre çalıştıktan sonra oraya çakılı kalıp, daha iyi bir noktaya geçme şansınız kalmadığını farkedebilirsiniz. Yaptığınız işin başkaları tarafından görülebilir olmaması ve yeni şeyler öğrenmenizi gerektirmemesi çok tehlikeli kariyer riskleri.

9 comments...

Yazılım geliştiricinin çevik olanı...

20 February 12, Monday @ 17:47

Çalıştığım şirkette epey bir süredir Agile (Çevik) yazılım geliştirme metotlarından biri olan Scrum (Ragbi oyununda takımın bir mesafeyi almak için kafa kol girişmesini ifade eden bir terim :) uygulanıyor.

Agile yaklaşımın temelinde gereklerin geliştirme süreci boyunca değişeceği, dolayısıyla yazılımın artımsal olarak kısa adımlarla geliştirilmesi, müşterilerin ve geliştiricilerin süreç boyunca etkileşimi, yazılımın her anında çalışabilir olması gibi bazı genel fikirler var. Scrum ise bu fikirlerden yola çıkıp geliştirme ve planlama sürecinin nasıl yürütüleceğini ayrıntılı olarak (ve süslü deyimlerle) tanımlayan bir yöntem.

Bu yöntemler hakkında detaylı bilgi internette bulunabilir, ben yalnızca deneyimlerimden yola çıkarak öznel görüşlerimi aktaracağım.

İlk olarak, Scrum geliştirme işinin teknik yönüyle ilgili çok az şey içeriyor. Kodlama standartları, sürüm kontrol, inşa, test, vb pratikleriniz olduğunu varsayıp devam edelim.

Scrum takımı, geliştiriciler, ürünün önceliklerini belirleyen bir product owner (ürün sorumlusu) ve Scrum süreçlerinin yürütülmesi, geliştiricileri bloklayan engellerin kaldırılması, varsa diğer takımlarla iletişim gibi işleri yapan ve belli aralıklarla değişebilen bir Scrum Master'dan (Scrum yöneticisi) oluşuyor.

Scrum süreci sabit sürelerle yapılan geliştirme hamleleri (sprint) şeklinde. Bu süre genelde birkaç hafta. Her sprint başında yapılacak işler planlanıyor ve sprint süresince bu planlama değiştirilmiyor. Tabii bu süre bazı işler için küçük bazıları için büyük. Scrum'ın buna çözümü, işleri kendi başına çalışan ve sorunun çözümünde bir miktar ilerlemeye karşılık gelen küçük adımlara bölmek ve her Sprint sonunda bir miktar çalışmayı ürüne katıp o adımı geçmiş olmak. Kağıt üzerinde mantıklı da gelse, uygulamada işler bu kadar basitçe adımlara ayrılamıyor elbette. Bazı durumlarda işi artımsal adımlara bölmek toplamda daha uzun zamanda bitmesine yol açabiliyor. Ara adımlarda çıkan ürünlerin kullanıcılara ulaşması da, bakım zorluğu yaratacaksa istenmeyen bir şey olabilir. Kimi zaman da sprint bitmeden bir özelliği yada hata düzeltmeyi ürüne katıp müşteriye sunmak isteyebilirsiniz. Dogmatik yaklaşmayıp bu tür durumlarda esnek davranabilirseniz sprint yönteminin genel olarak zararlı olmadığını düşünüyorum.

Her gün belirli bir saatte, ekipteki herkesin geçen gün ne yaptığını, bugün ne üzerinde çalışacağını ve devam etmesine engel olabilecek her türlü engeli anlattığı günlük toplantı (standup) yapılıyor. Bu toplantının ayakta ve aynı odada yapılması vb gibi bir dizi kural var ama siz şekilselliğe değil amaca bakın. Önemli olan kısa sürmesi, herkesin birkaç cümle söyleyip birbirinin yaptığından haberdar olması. Amaç ekibi onbeş dakkada senkronize edip, o gün başka toplantıların yapılmasına engel olmak! Scrum'ın pratikte en faydalı uygulaması bence bu.

Akla gelen her özellik ve geliştirme önerisi, user story (kullanıcı hikayesi) adı verilen ve genellikle "bir Gazeteci olarak kelime işlem programında sözcükleri sayabileceğim bir özellik istiyorum, böylece istenen uzunluğu aşmadan yazabileceğim" gibi birinci ağızdan yazılmış fonksiyonel iş tanımları olarak, backlog (yığılmış iş) adı verilen bir listeye ekleniyor. Sprint başında takım bu listeden o sprint süresince yapılacak işleri seçiyor. İşlerin fonksiyonel ve açık biçimde belirtilmesi (user story'ler işin tamamlanma koşullarını ve çeşitli testleri de içerebilir) faydalı bir yaklaşım, ancak backlog fikrini doğru bulmuyorum. Bu konuda Rework çok daha akıllıca bir yöntem öneriyor: Uzun listeler moral bozmaktan başka bir işe yaramaz. Eğer bir işi bir kenara yazmadığınızda unutuluyorsa zaten sandığınız kadar önemli ve yapılması gereken bir şey değildir. Müşteriler ile sürekli bir iletişiminiz varsa zaten size en öncelikli ve gerekli işi sürekli hatırlatacaklardır.

Burada bir sorun da, ürün kalitesini arttıracak ama müşteriye direk yansımayan ufak işleri sıraya almanın çok zor olması. Bunları ya kendi başınıza yapacaksınız, değerlendirmelerde gözükmeyecek ve bunlara harcadığınız zamanın hesabını veremeyeceksiniz. Ya da bunlara birer user story oluşturmak yada eldekilerden birine eklemek için hem zaman hem de ekibi ikna edip sıraya aldırmak için enerji harcayacaksınız.

Backlog'a atılan user story'ler takım tarafından zorluk ve tamamlanma sürelerine göre puanlanıyor. Bu puanlar o sprint'te başlanacak işleri belirlerken ve süreç boyunca burndown chart, velocity gibi süslü isimleri olmasına karşın aslında oldukça basit istatistikleri oluştururken kullanılıyor. Amaç takımın verimini ve işlerin yürüme hızını gözlemlemek ama burada detaylarına girmeyeceğim bir dizi kurnazca yöntemle yapılmalarına rağmen neredeyse hiç bir işe yaramıyorlar. Puanlama, eğer kendinizi kandırmıyorsanız, işe başlamadan bilemeyiz demekten ibaret. Diğer istatistikler ise elma ile armutu karşılaştırıyor.

Bu ölçme girişimleri ar-ge'yi teneke kutu üretimi sanan yöneticileri tatmin etmek için icat edilmiş olsa gerek. Onlara kötü bir haberim var, eğer projeyi en ufak detayına kadar kavrayabilecek kadar bilginiz yoksa bir ar-ge projesini yönetemezsiniz. İyi niyetliler sizi terkeder, kötü niyetliler metriklerinizi kandırır. Bu noktada maalesef velocity yıllar öncesinin kod satırı sayısı kavramından bir adım öteye geçebilmiş değil. Benim önerim şu: projeyi takip mi etmek istiyorsunuz, gidip commit eposta listesini okuyacaksınız. Anlamıyorum olup biteni diyorsanız da proje yönetmeyin lütfen!

Scrum kabaca böyle. Doğru uygularsanız faydalı olabilecek bazı pratikleri var. Bir bütün olarak almayıp, her pratik için bu doğru mu? ve benim durumuma uygun mu? diye sorgulamanızda fayda var. Şekilselliklerinden ve seremonilerinden ise kaçının derim, gülünç duruma düşmeyin.

Agile felsefesine daha uygun başka uygulamalar da mevcut. Bu yazının kapsamı dışındalar, o yüzden netten kendiniz araştırabilirsiniz. Ayrıca herhangi bir çelişki halinde Rework kuralları daima geçiş üstünlüğüne sahiptir :)

3 comments...

Yeni dünyadan bir takım izlenimler

02 January 12, Monday @ 21:20

Bir yıla yakın süredir Amerika'da yazılımcı olarak çalışmaktayım. Çalıştığım şirket Princeton'dan akademik olarak ortaya çıkıp, önce bir startup oldu, daha sonra da büyük bir şirket tarafından satın alındı. Bu tür hikayeler yeni dünyada çok sıradan, girişimcilik günlük yaşamın parçası. Peki biz (yalnızca Türkiye değil, bütün Avrupa) bu kültürden ne kadar uzağız?

Silikon vadisinin gizli tarihi adlı bu video, Amerikan üniversitelerinin dünya savaşının peşinden savunma projelerinde yer almaya başlamasını, bu işlerin içindeki Frederick Terman gibi profesörlerin Stanford'a gelerek, öğrencilerin şirketler kurarak araştırmalarını ticarileştirmelerini teşvik etmesi, böylece vadinin HP, Intel, vb gibi ilk nesil teknoloji firmalarının ortaya çıkışını anlatıyor. Ortaya çıkan model çok özgün. Üniversite temel bilim araştırmalarının yapıldığı bir merkez görevini alıyor. Bu araştırmaları yapan öğrenci ve profesörler, işi somut bir ürüne dökmek istedikleri zaman dışarı çıkıp şirket kuruyorlar ve üniversite onlara araştırma sonuçlarının kullanımı için gerekli her türlü lisans ve kolaylığı sağlıyor.

Modelin başarısı, amacı insanlığın bilgi birikimini arttırmak olan araştırma çabaları ile, insanlığın bir ihtiyacını karşılamayı hedefleyen geliştirme çabalarını birbirinden ayırmış olmasında bence. Araştırma, önceden planlanamayan ve kısa vadede kâr getirmeyen, dolayısıyla bir zaman engeli taşımadan özgürce yapılabileceği bol kaynaklara ve ortama ihtiyaç duyan bir faaliyet. Geliştirme ise, gene planlaması çok zor da olsa, ihtiyaç duyacağı kaynakların gerekliliğini ispatlayabildiği ve tasarım sınırları dahilinde yürütüldüğü sürece ortaya daha başarılı ürünler çıkaran bir süreç. Akademisyenlerin özgürce bu iki dünya arasında geçiş yapabilmesi, doğru bilgilerin doğru ürünlere dönüşmesini çok destekleyen bir sistem.

Türkiye'de bu konudaki ilk sorun akademi ve özel sektör arasındaki büyük maaş uçurumu. Pek çok meslek gibi akademisyen maaşı da rahat bir hayat sürmeye yeterli değil, bu yüzden çoğu parlak genç özel sektörde bol mesaili dolayısıyla araştırma ya da boş vakit içermeyen bir işe girip akademiden tamamen kopuyor. Geçim sorunu yaşamayıp akademide kalabilenler ise devlet memurluğuna tabiyetten öyle kolay kolay şirket kurmak ya da ticari işlere girmek imkanına sahip değiller. Bu ekonomik nedenler üniversitelerdeki hocaların ve dolayısıyla eğitimin kalitesini de düşürüyor. Üniversite devletin verdiği paraya ya da zengin öğrencilerin harçlarına bağlı yaşayan bir meslek okulu pozisyonuna girince, buradan kendi başına ayakta durmayı öğrenmeden çıkan öğrenci de, kendine güvenden yoksun kalıyor. Tek marifeti zamanında dedesinin doğru bir araziyi satın almış olması ya da devlet tarafından zorla zengin edilmiş olmak olan uyduruk bir iş adamının yanında çalışmayı bile büyük bir hedef olarak görüyor. O adamla rekabet edebilecek bir iş kurmayı düşünmüyor bile.

Silikon vadisindeki model kurulduktan sonra, para kaynağı konusunda büyük değişimler geçirmiş. Savunma sanayi yerine normal tüketiciye yönelik ürünler geliştirmeye başlamış ve ilk başta kendi imkanlarıyla para bulan şirketler için bir sürü özel yatırımcı ve yatırım fonu ortaya çıkarak bugün Venture Capital denen girişim sermayesi piyasasını oluşturmuş.

Bu sektörü oluşturan neden tabii ki girişimlerin büyük kazanç getirme şanslarının yüksek oluşu. Ancak sektörün bu kadar büyümesinin nedeni sırf bu değil. Basit bir hesap yaptım, yaklaşık 10.000$ gibi bir miktardan daha büyük paralar için, bu parayı Amerika'dan Türkiye'ye yollamak, 3 aylık faize koyup sonra geri getirmek, tüm transfer ücretlerine rağmen, Amerika'da herhangi bir klasik faiz enstrümanına yatırmaktan daha kârlı. Faiz kazançları bu kadar düşük olunca, para sahipleri ya oturup somut bir iş yapmak, ya da parayı bu tür girişimlere yatırmak zorunda kalıyor. Bizde ise bırakın faizi, taksi plakası gibi absürd enstrümanlarla parayla para kazanmak varken parayı bir işe harcamak akıllıca bir hareket olmuyor (nasıl bu kadar yüksek faiz verebildiğimiz ise Türkiye ekonomisinin büyüdüğünü sananları yakın bir tarihte çok şaşırtacak ayrı bir hikaye).

Bu iki durumun oluşturduğu bir üçüncü durum daha var, o da girişimcilerin profili. Amerikan teknoloji şirketlerinin yatırımcı, kurucu ve üst düzey çalışanlarının büyük kısmı akademi ya da endüstriden gelen ve bağlarını koparmamış kişiler, zenginlik kaynakları ise hep teknolojik başarılar. Bu profilin getirdiği avantaj bu kişilerin zenginliklerini yeni girişimler için kullanma yüzdelerinin oldukça yüksek olması. Bu da gözü çalışanlarına iki saat daha fazladan mesai yaptırma, primlerini vermeme ve ar-ge harcamalarını mümkün olduğunca kısma derdinde olan feodal işadamı profiline göre büyük bir avantaj.

Türkiye'de "üniversite sanayi işbirliği" üzerine çok yazılıp çizildi. Bu konuda Tübitak gibi kurumlar kuruldu çalışmalar yapıldı. Cahit Arf'ın anılarında özellikle sanayicilerin Tübitak'a gelip şöyle teknik problemim var çözün diye istekte bulunmamalarından yakındığını hatırlıyorum. Yukardaki modeli gördükten sonra bunun niye yürümediğini anlamak kolay. Girişim o yönde çalışmıyor, yeniliği sizin yapıp müşteriye götürmeniz gerekli. Zamanla Tübitak da (özellikle son zamandaki mesela Feza Gürsey Enstitüsünün kapatılması gibi değişikliklerle) temel bilim desteğini azaltıp ürüne yönelik geliştirme yapan dolayısıyla çeşitli konularda özel sektörü de baltalayan bir yapı haline geldi. Teorik araştırmalar olmadan yapılan geliştirme yabancı ürünlerin ucuz benzerlerini yapmaktan öteye gidemiyor maalesef.

Son olarak tüm bu faktörler sağlanıp, bir başlangıç ivmesi sağlansa bile çok zamana ihtiyaç olacak, çünkü neredeyse bir yüzyılda ve sayısız başarı ve başarısızlıktan sonra edinilmiş bir kültüre sahip olmak kolay değil.

10 comments...

Fatih projesi üzerine

16 October 11, Sunday @ 18:30

Zeki Bildirici Linux gezegenindeki bir blog yazısında, Fatih projesinden bahsedip, bu projede özgür yazılım kullanılması için mücadele etmeye bir çağrı yapmış.

Bu konudaki diğer yazılarda da ıskalanan bazı önemli noktalar gördüm. Projenin olası dört katmanı üzerine kendi düşüncelerimi açıklamaya çalışacağım.

Donanım, bu işin en alt katmanı. Akıllı tahta ve tabletlerden bahsediliyor. Bu katmanda belli bir teknoloji seçimi yapmanın yada tek tip ürün kullanmanın aptalca olduğunu düşünüyorum. Çünkü bu aletler her gün gelişiyor ve giriş sistemleri (dokunmatik ekran, hareket algılama, ses tanıma, vb) ile görüntüleme sistemleri (lcd, e-ink, kıvrılabilir ekranlar, vb) sürekli devrimsel değişiklikler geçirdiği için tek bir modele yada aygıta çakılı kalıp güncelleşememek tehlikesi var.

Bu alanda üretimi yerli yapmanın bir faydası olacağına inanmıyorum. Sonuçta herkes gidip işlemciyi ve ekranı Samsung, vb den alacak. Çin kalkıp iPhone'u biz ürettik diye böbürlense kargalar bile güler, ama Türkiye'de araba montajı yapmayı bir başarı sanıyoruz. Bu çağda değerli olan şey üretim değil tasarım, onu da donanım alanında yapmak çok büyük kaynak ve zaman ve elimizde hiç olmayan bir know-how istiyor. Malesef devlet ar-ge kaynaklarını temel bilimlerden çekip, ürün üretimine yönelik ve aslında özel sektörün yürütmesi gereken alanlara aktarıyor. Fizik, kimya ve biyoloji gibi temel bilimlere yatırım yapılmayınca da mesela yeni bir ekran teknolojisi gibi bir şeyin yerli olarak ortaya çıkması imkansız.

En mantıklı yol, tek tip aygıt üzerinde standartlaşmayıp, belli özelliklere (işlem kapasitesi, ergonomi, sağlamlık, fiyat) uyan birden fazla tedarikçiyi kullanmak. Yerli üretici elbette güzel olur ama devlet enerjisini bunu bu katmanda değil de daha üst katmanlarda sağlamaya yönlendirmeli.

İşletim Sistemi, gene bu projenin önemsiz ve alt katmanlarından biri. Temel giriş çıkış işlevlerini, çoklu çalışma ve ağ iletişimi imkanlarını sağlayan herhangi bir sistem yeterli olur. Ancak tek bir üreticiye bağlı kalmamak ve en önemlisi farklı donanımlara kolayca aktarabilmek açısında mutlaka bir özgür yazılım seçilmeli.

Bu katmandaki en mantıklı seçim Linux. Özellikle gömülü sistemlerdeki yaygınlığı, kolayca özelleştirilebilmesi ve bilgi birikiminin tamamen özgür olması nedenleriyle. Teknik destek alınabilecek Tübitak gibi bir devlet kurumu da olduğu göz önüne alınırsa, Pardus projesi bir Linux dağıtımı olarak en doğru seçim gibi görünüyor.

Yazılım altyapısı işin en önemli noktası. Herhangi bir iPad benzeri aleti çocuğun eline verince iş bitmiyor. Mesela ders içeriği çocuğun elindeki alete nasıl yüklenecek, güncelleme ve düzeltmeler nasıl dağıtılacak, sınav ve ödevler, istatistiki bilgiler bu aletlerden toplanıp merkezi bir sistemde nasıl analiz edilecek, ders anlatımı sırasında aletin uygun içeriği göstermesi nasıl sağlanacak, ders ve yardımcı içerikler hocalar tarafından nasıl üretilecek, bu işlerde hangi araçlar ve formatlar kullanılacak. Bunlar küçük ölçekte bile kolay olmayan, MEB ölçeğinde ise çok zor problemler. Bir de mesela ses tanıma ve ses sentezi gibi teknolojilere Türkçe desteği verilmesi gibi büyük çaplı ve önemli işler var.

Varolan teknolojiler bu iş için elverişli değil. PDF bu aygıtların ekranlarına uygun bir format değil, Flash kapalı olması yanında yeni giriş sistemlerini desteklemiyor, öğrencilerin video dersleri izlemesini isterseniz, bu videoyu alette depolamanın ayrı problem, ağdan sunmanın ayrı problem olduğunu göreceksiniz.

İşte asıl katma değerin olduğu (çünkü dünyada kimsede böyle bir sistem yok), ve yerli imkanlarla başarabileceğimiz (çünkü yazılım için büyük mali kaynaklar ve üretim tesisleri değil, doğru vizyon ve yetenekli yazılımcılar gerekiyor yalnızca) alan burası.

Bunun yürütücüsü kim olur bilemiyorum. Devlet kurumlarında yazılım geliştirme konusunda bir birikim yok. Pardus'un sürekli kaybettiği ve yerlerine yenisini koymadığı deneyimli elemanları ve daha halen devam eden yönetim yanlışlıkları da işin bu tarafını başaramayacaklarını gösteriyor. Özel sektörden biri yaparsa devlete satamaz, yada şöyle diyelim, devlete satabilecek olan özel sektör bu işi doğru dürüst yapamayacağı gibi yapmak niyetinde de olmaz. İhaleyi zaten ucuza almış, ilk yapacakları iş kârı arttırmak için işi en ucuza yapmaya çalışmak. Malesef ar-ge ucuza getirmeye çalışarak yada şark kurnazlığı ile yapılabilecek bir iş değil.

İçerik kısmı ise MEB'in halledeceği bir iş. Burada benim katabileceğim tek fikir, klasik kitap içeriğinin bu işe uygun olmadığı. Hipermetin (HTML, vb) bile ideal çözüm değil. En güçlü içerik, mutlaka çokluortam içeren ve etkileşimli bir deney ortamı sunan bir sanal dünya olacaktır.

Bu konuda bazı üniversitelerin güzel girişimleri var. Mesela Sebastian Thrun ve Peter Norvig'in yapay zeka derslerini 24 saatte 80.000 kişi çalışmış. Derslerin anlatımları tabiki çok güzel ve ara sorular ve sınavlarla zenginleştirilmiş. Bu tür eğitim teknolojilerinin en büyük avantajı alanının en iyisi kişiler tarafından büyük emek harcanarak bir kere oluşturulacak derslerin az bir maliyetle ve coğrafi engelleri aşarak çok sayıda kişiye ulaştırılabilmesi.

3 comments...

robocup istanbul

16 December 10, Thursday @ 18:52

Tüm dünyadan bilim insanlarının, geliştirdikleri robot futbol takımlarıyla katıldığı bir yarışma olan RoboCup 2011, Boğaziçi Üniversitesinin ev sahipliğinde 5-11 Temmuz 2011 tarihleri arasında İstanbul'da yapılacak.

Bu güzel olayın basındaki yankıları ise içler acısı. Etkinliğin ana sitesine bakıp yada düzenleme komitesine sorup bilgi almayı beceremeyen zeka özürlü basınımız nereden çıktığı belli olmayan bazı yanlış bilgiler üretmiş.

Bu yanlışların en acıklısı ise, neredeyse on yıldır bu işin içinde olup kazandıkları başarılar ve uluslararası robotik camiasındaki çalışmalarıyla bu etkinliğe ev sahipliği yapabilmememizi sağlayan bilim insanlarımızı sallamayıp, etkinliğe "İstanbul"un ev sahipliği yaptığını yazmak.

Haberde konuşulan kişiler bu durumdan hiç rahatsız olmadı mı acaba. Üniversitelerimiz şark kurnazlığını bırakıp, gerek uluslararası alanda gerek yurtiçinde birlikte ve etik kurallara uygun şekilde çalışmayı öğrenebilecekler mi göreceğiz.

1 comments...