Düşünüyorum
V8'in gayet güzel bir arabirimi var, nodejs projesinden de görülebileneceği gibi geliştirme yapmakda oldukça kolay, javascript oldukça yaygın bir dil ve geniş bir kullanıcı ağı var.
Peki, acaba linux kerneli ve V8 javascript engine kullanan bir işletim sistemi olamaz mı? Linux boot sürecinde init yerine V8'i çalıştırsa ve V8 her bir terminal için javascript shell çalıştırsa? şu anda V8'in shell erişimi sadece bir kaç ufak tefek komutdan oluşuyor ancak güzel bir geliştirici katkısı ile hazır haline geçmesi pek sorun olmaz diye düşünüyorum. sistem üzerinde bulunacak tüm kütüphaneler sadece ve sadece kernel'in ve V8'in ihtiyaç duyacağı kütüphaneler olsa, bir JsOS'un prematüre hali olabilir mi?
(Yazar) - Sevgili günlük
(Günlük) - Her istediğinde hatırlayacağın birimiyim ben?
(Yazar) - ...........
(Günlük) - Aleyhinde kullanacağım
Dikkat edilmesi gereken projeler
Son zamanlarda ilgilenmeye başladığım uygulama/projelerden bazılarını yazayım dedim, özellikle cometd projesine göz atmanızda fayda var, malum html5 ile gelen web socket'leri ve cometd birleşince realtime web için oldukça iyi bir adım atmış olacağız.
cometd - bayeux (http://cometdproject.dojotoolkit.org/)
tornadoweb (www.tornadoweb.org)
Bölüm 2) Kaynak kod yönetim sistemleri
Tek tabanca çalışan yazılımcılarda gözlemlediğim diğer bir dezavantaj ise kaynak kod yönetimi için her hangi bir araç ihtiyacı hissetmemesidir. Bu nedenle özelliklede takım çalışması sırasında en çok ihtiyaç duyacağınız kaynak kod yönetim araçlarının eğitimi ve kullanım alışkanlığının oluşturulması zaman alacaktır. Ticari olarak geliştirilen Kaynak kod yönetim araçları özellikle bir startup için oldukça maliyetli olabilir, bu neden ile özgür yazılım olarak kullanılan araçlar içerisinden en çok kullanılanlarına bir göz atalım, CVS, GIT ve Subversion, her aracın kendine özgü avantajları ve dez avantajları mevcuttur bu araçlardan hangisinin kullanılacağı ise genel olarak proje içerisinde yer alan yazılımcıların genel olarak hangi aracı daha rahat kullanabileceği ile ilgilidir, zamanla mevcut kullanılan kaynak kod yönetim aracının değiştirilmesi söz konusu olabilir.
GIT
Git, linus torwalds tarafından linux kernel kaynak kodunun idaresi için geliştirilmeye başlanmış ve ardından pek çok geliştiricinin desteği ile gelişimine devam etmiştir, linux kernel'i gibi oldukça büyük ve binlerce kişi tarafından geliştirilen bir uygulama için kullanılan bu araç pek çok kişinin ve şirketin dikkatini çekmiş ve son bir yılda oldukça popülerleşmeye başlamıştır. GIT diğer kaynak kod yönetim uygulamarından bazı özellikleri ile ayrılmaktadır, başlıca özellikleri dağıtık bir mimari sunmaktadır, bir depo'yu kullanmak istediğinizde deponun tüm tarihi bilgisinide alırsınız. Bir depo ihtiyacı duymaz ve yerel olarak çalışabilir, bu sebeble bir git sunucusuna ihtiyacınız yoktur.
CVS
1986 dan beri geliştirilen ve oldukça sık kullanılan bir araçtır, eski olması nedeni ile pek çok windows, unix ve mac üzerinde istemcileri mevcutur. modüler yapısı sayesinde pek çok araç ile entegre çalışabilir. pluginleri sayesinde RSS üretebilir, commit logları farklı veri tabanı üzerinde tutulabilinir. Ayrıca web üzerinden de kaynak kodlar üzerindeki değişiklik takip edilebilinir, rss ve mailing ile son değişiklikleri geliştiricilere iletebilirsiniz.
Subversion
2000 yıllında geliştirilmeye başlayan bu araç CVS de bulunan pek çok zenginliği taşımaktadır. moduler yapısı sayesinde CVS için kullanabileceğiniz yardımcı araçları subversion içinde bulabilirsiniz. subversiyonun geliştirilme amaçlarından biri olan CVS'de bulunan bir takım önemli problemleri kapatmak ve geliştiriciler için daha kolay bir kullanım sunmaktır. Subversiyonda'da commit loglarını ayrı veri tabanında tutabilir, web arabirimi ile kaynak kodlar üzerindeki değişiklikleri takip edebilirsiniz, rss ve mailing ile son değişiklikleri geliştiricilere iletebilirsiniz.
Unutmamanız gereken şey yukardaki her araç sadece ve sadece kaynak kod yönetimi için geliştirilmiştir, rss, mailing ve web arabirimleri için bu araçlar ile entegre çalışan farklı uygulamaların mevcut olduğu ve içerisinde hazır çözüm olarak gelmediğidir.
Kişisel tercihim olarak kullanım ve yönetim kolaylığı nedeni ile subversiyon'dur ancak projenin ihtiyaçları doğrultusunda bu seçim değişebilir.
Kaynak kod yönetim sistemlerinin kullanılmaması pek çok girişim ve projenin geliştirme süreçleri büyüme arttıkça doğru orantılı olarak uzamakta veya gelişimini devam ettirememesine neden olmaktadır. Geliştiricilerin bu tür araçları kullanmaya alıştırmak için ise benim kişisel yöntemlerimden biri commit mesajlarına ufak tefek proje ile ilgisiz genelde şakacı yada gönderme yapan mesajlar geçmektir. bir süre sonra commit mesajları geliştiriciler arasında online iletişim aracı haline gelecektir 
$ svn commit dosya.txt -m "fixed #5454 > > > detan böcekkıran böceklerle olan savaşında bir kez daha kahramanca galip gelir."
$ svn commit dosya.txt -m " > typo hatası, indentlere dikkat etmek lazım gelir. > > çeşme başında gezmeli, > güzeli uzaktan süzmeli, > eğer gönlü var ise, > istemeye gitmeli."
Bölüm 1) Dökümantasyon
Türkiye'de özellikle yazılım üzerine eğitim almış kişiler, eğitim yöntemleri nedeni ile hep bireysel çalışmaya odaklılardır. Bunun sonucu olarak tek tabanca tüm yazılımı tamamlamak normal bir şey gibidir. Bu yüzden yazılımın dökümantasyonuyla ilgili pek fazla çalışma yapılmaz, bu nasıl yapılır, ne tür araçlar kullanılır bilinmez. Eğer bir startup için bir yazılımcı ile anlaşacaksanız sormanız gereken şeylerden biri kullanılacak olan dili'de dikkate alarak örn: PHPDoc, JavaDoc gibi yazılımın kaynak kodu üzerinden dökümantasyon çıkartmak için kullanılan söz dizimi hakkında bilgi sahibi olup olmadığı, daha önce bu tür bir şey yapıp yapmadığı olmalıdır. Bu söz dizimleri öğrenmesi oldukça kolay ve sadece 5 dk. alacak şeylerdir dolayısı ile bilip bilmemesi pek fazla sorun değil ancak bu sorumluluğunun farkında olması açısından önemli bir göstergedir.
Bir proje yaşadığı sürece pek çok farklı yazılımcı dahil olacak veya ayrılacaktır, ayrıldığında projenin devam edebilmesi ve yeni gelen yazılımcıların hızlıca projeye dahil olması açısından önemli bir ayrıntıdır aksi halde her yeni katılan yazılımcı tekerleği yeniden hazırlayacaktır. Aşağıda görebileceğiniz gibi kaynak kod üzerinden dökümantasyon oluşturmak aslında oldukça kolay bir işlemdir. Her ne kadar örnek PHP ve PHPDoc üzerinden verilmiş olsada hemen hemen her dil için benzeri araçları bulmak yada uygulamak mümkün.
Söz dizimi: /** * String sınıfı string işlemleri ile ilgili * doğrulama ve ayıklama işlevlerini yerine * getirmek amacı ile hazırlanmıştır. * @package projectname * @subpackage dogrulama */ class String { /** * parametre olarak verilen string içerisinde eğer var ise * 0-31 ascii kodu arasındaki kontrol karakterlerini siler * ve temizlenmiş string verisini geri döndürür. * {@source 3 1} * @param string $string kullanıcıdan gelen string veri * @return string kontrol karakterlerinden arındırılmış string veri * @access public */ static public function clearControlChars($string) { return preg_replace('#\p{C}#u', '', $string); } }
Projenin kod tabanındaki dökümantasyon proje büyüdükçe önem kazanmaktadır, yeni katılan geliştiricilerin başları sıkıştıkça bakabilecekleri bir kaynak bulunması geliştiricileri oldukça rahat hissettirecektir. Dökümante edilmemiş bir kod yığını içerisinde yeni bir geliştirici her hangi bir sorunun kaynağını ararken veya yeni bir geliştirmeyi eklerken kullanabileceği araçları tam olarak bilemeyeceğinden dolayı bunun için en kısa yol olan "bir bilene soralım" yolunu izleyecektir, bu durum daha tecrübeli olan geliştiriciyi çalışırken bölmek ve dikkatini dağıtmak anlamına gelmektedir, dikkati dağılan geliştirici tekrar konsantre olmak için bir süre oyalanacak ve ilerleyen zamanlarda bu durumun devam etmesi geliştirici üzerinde huzursuzluğa neden olacaktır. Diğer bir durum, yeni katılan geliştirici soru sormak yerine çözümü kaynak kod içerisinde aramayı denemesidir, ancak bu da çok fazla zaman alacaktır ki bir süre sonra ne aradığını hatta neden aradığını bile unutabilir. (kendimden biliyorum ) yukarıda bahsedilenler, dışarıdan bakıldığında gelişticinin suyu çıkıncaya kadar çalıştırılacağı veya çalıştırıldığı izlenimini verebilir ancak anlatılmak istenen, dikkat dağıtıcı unsurları azaltmak veya problemlerin cevaplarını kolayca bulmanın yolları var iken bunların görmezden gelinmemesidir. İyisimi siz dökümantasyona önem verin.
(Yazar) Sevgili günlük...
(Günlük) Sizin yolunuz pek sık düşer oldu, hayırdır?
(Yazar) Geçmi kalıyorum?
(Günlük) Geç kalmıyorsun, gitmesini, geçmesini bekliyorsun, bekleme...
yazılım geliştirme ve ölçeklenebilirlilik
Projeler ve yazılım ayrılamayan ikilidir, projeleri gerçekleştiren kişilerin kullandığı diller ve teknolojiler, projenin veya fikrin gerçekleştirilmesini sağlayan yazılımı oluştururken aynı zamanda projenin biçimlenmesinde kimi zaman olumsuz kimi zaman olumlu katkıda bulunurlar.
Türkiyede özellikle yoğun trafik yaşayan web projelerinin azlığı, yazılımcıların ilgi ve tecrübesinin olmamasını pek çok başarılı olabilecek projenin henüz daha doğmadan yok olmasına neden oluyor. Şöyle düşünün, dailymotion yada youtube daha henüz oluşturulmamış iken bir fikir sahibi olarak (teknik bir kişi olmadığınızı var sayarak) online video sitesi kurmak geldi ve çeşitli gelir modelleri belirlediniz, etrafınızdaki yazılımcılardan bu işin yapılabilinirliliği hakkında bilgi ve fiyat almak istediğinizde size bir kaç çözüm ile birlikte bir kaç fiyat çıkartılacaktır, sizde güvendiğiniz ve cebinize uygun fiyatı veren yazılımcı veya yazılımcı ekip ile yola çıktınız.
Projeniz bittiğinde ise aslında sizin elinizde olan sadece yapılacak iş için yapılabilirliliğine ait bir kanıt niteliğinde ürün oldu ancak siz henüz bunu fark etmediniz, fark etmenizi sağlayacak senaryo ise:
ilk haftada saniyede 100 request almaya başladınız, sisteminiz afalladı çünkü yazılımcılarınız ne yazıkkı ölçeklenebilirlik hakkında pek fazla bilgiye sahip değillerdi, dağıtık dosya sistemi için nfs kullanıldı çünkü daha bilinir ve daha kolay geldi, sabit içerikleri ayırmadınız, ön bellek sistemi dosya dizin seviyesinde kaldı, oturum yönetimi dosya dizin seviyesinde çalışıyor. veri tabanına yapılan sorgular önbelleklenmediği ve kimi update işlemleri için (gösterim arttırımı veya azaltımı) veri tabanına erişim yapılıyor. Tüm bu unsurların sonunda sisteminiz gelen trafiğe yanıt veremeyecek duruma gelebilir. Problemi aşmak için büyüme kaçınılmaz ancak nasıl?
Yeni çıkmış bir servisin birden bu duruma düşmesi oldukça kötü olacaktır, bu neden ile yazılım ekibinizin veya yazılımcınızın bu unsurları en başta düşünmesi ve tedbir alması gerekmektedir.
Bu unsurlara göre yazılım tasarımı nasıl olmalıdır? Kullanılabilinir araçlar, teknikler ve teknolojiler nelerdir? Büyüme problemleri, çözümleri ve maliyeti ile ilgili bir süre yazmak bir şeyler "zırvalamak" istiyorum, umarım faydalı olur.
(Yazar) Sevgili günlük...
(Günlük) beni hatırladığına sevindim, efendim?
(Yazar) Yanlış mı yapıyorum sürekli?
(Günlük) Hayatın içerisinde yapılanlar, yapıldıkları sırada yanlış değildir, bu yüzden şimdi düşünme ilerde düşünürsün.
Yeni bir başlangıç
Son bir senedir çalıştığım firma olan Cetech‘deki görevimden 1 Kasım 2008 itibari ile ayrılmış bulunuyorum. Çalıştığım dönem boyunca kimi zaman neşeli kimi zaman ise yoğun ve yorucu tempo ile birlikte olduğum iş arkadaşlarıma teşekkür ediyorum.
Ayrılma nedenim ise kişisel bir projemi gerçekleştirmek için zaman oluşturabilmek idi, projenin sadece teknik yönüyle değil tüm ilerleyişini paylaşmak istediğimden girişim günlüğü isimli günlüğü açtım, sadece bana ait projelerin durumlarını değil, kendi girişimleri olan diğer insanların da yazabilecekleri, projeleri ile ilgili durum bilgisini yayınlayabilecekleri bir günlük olmasını istiyorum ancak henüz tam anlamı ile olgunlaşmadığından bu beklentimin gerçekleşmesi oldukça güç.
Üzerinde çalışmak istediğim proje ile her şeye yeni bir başlangıç yapmak istiyorum, umarım yürümek istediğim yere doğru gidebilirim.
new photoStream released
photoStream plugin 0.0.2 relased. some changes:
* fixed multiple click running on effects
* fixed new instance for each click
* added lastPhoto and nextPhoto parameter for no more photo
* added containerElementClassName parameter for XHTML (id must be uniq on page)
* added nextClickableElementClassName and backClickableElementClassName for XHTML
if you want to learn what is the photoStream look at here, if you want to learn what is change look at here
PhotoStream
Daha önce Flickr photoStream başlıklı yazıda belirttiğim kodu
http://selam.sonsuzdongu.com/streamPhoto/ adresinde yayınlamaya başladım. Kullanmak isteyerler için download bölümü mevcut, buna karşın en büyük bekletim kodun geliştirilmesi ve farklı sunucu taraflı verileri desteklemesi ve elbette safari için çalışır duruma gelmesi 
Flickr photoStream
Bu hafta sonu evde prototype ve script.aculo.us kullanarak photoStream sınıfı yazdım henüz safari ile çalışmadığından kodu yayınlamıyorum ama başlıca özelliklerini aşağıda sıralayabilirim
- resim geçişleri için sıradaki fotoğraf bilgilerini ajax ile json formatında alması
- preview için 2 yada daha fazla fotoğraf kullanabilme (1 resimde kullanılabilinir ancak tavsiye etmiyorum),
- dikey veya yatay çalışabilme,
- birden fazla fotoğraf seti ile aynı anda çalışabilme,
- daha önce yapılan ajax isteklerinin ön belleğe alınması
Ancak bu ilk javascript denemem olduğu için kodun ne okunabilirliliği nede dökümantasyonu tam. bunları ve demolarını ekleyip bir süre sonra burada yayınlayacağım.