Hikaye 2007 yılında Web 2.0 kelimesinin Türkiye’de kullanılmaya başlandığı ilk zamanlara dayanıyor. Daha doğrusu ne olduğuna dair mantığın dünyada anlaşıldığı zamanlardan bir yada iki yıl sonrasına… Lise 2’de okuyorum ve Romanya’da uluslar arası bir programlama yarışması olduğunu öğreniyorum. Buna katılmak için bir proje düşünüyorum. O zamanlarda da Ajax gibi teknolojiler revaçta. Bişiy yaparım ben bunla ki düşüncesiyle bir web projesi yapmaya başlıyorum. Konu da öğrencilerin okul hayatlarını internet üzerinden yönetebilmesi için tasarlanan, her yerden erişilebilen, pratik bir web servisi. Sonra mySchoolog doğdu. Hata 1: Web 2.0’ı yanlış anlamak
Web 2.0, Web 3.0, Web x.0… ne olduğu hiç fark etmez. Öncelikle metodolojiden ziyade trendin felsefesiyle ilgilenmelisiniz. Fiziksel özellikler çabuk değişir fakat bir trendi ayakta tutan insanların zihniyetidir, kullanıcı alışkanlıklarıdır. Örneğin Web 2.0 dendiğinde akla gelen şeyler aşağı yukarı şunlardı:
İçeriği kullanıcı üretecek
Güzel bir logo olacak, logonun aşağıya doğru ters ayna görüntüsü olacak
Kullanıcılarla iletişim kutucukları pop-up şeklinde açılacak
Renkli container’ların ve kutucukların köşeleri yuvarlak olacak
10pt-12pt gibi ufak yazılar kullanmak yerine daha kısa öz ve rahat okunabilen yazılar.
İçerik etiketleme, içeriğin diğer kullanıcılarla paylaşımı (sosyal ağ mantığı)
Sayfa baştan yüklenmeden değişen dinamik içerikler (Ajax)
Her web servisinin bir blog’u olacak. Blog olmasa bile çeşitli konularda RSS sağlanacak. Bu tip bir çok web 2.0 karakteristiği mySchoolog’da oldukça güzel bir şekilde uygulanıyordu. Fakat kullanıcıların %90’ının umrunda olmayan şeyler bunlar. Kullanıcı alışkanlıklarını kazanabilen, basitliği ve yüzeyselliği sağlayabilen siteler rakiplerine göre maça önde başlıyorlar. Önemli olan teknik altyapı veya ufak detaylar değil, kullanıcının sistemi niye kullanması gerektiğidir, sistemin uygulanabilirliğidir (fizibilitesidir).
Her şeyden önce uygulanabilir ve tutacak fikri bulmak oldukça önemli.
Hata 2: Az bilgiyle çok iş yapmak
Dönüp mySchoolog yazılımının kaynak kodlarına baktığımda kendim bile anlayamadığım bir sistem mevcut. Öncelikle sistemi kodlayacak yazılımcı(lar)ın kullanacakları programlama diline, veritabanı teknolojilerine hakim olmaları gerek. Yazılımcı, programlama dilinin design pattern’larını (tasarım örüntüleri - arayüz tasarımı ile ilgili bir konu değildir) iyi bilmeli ve piyasadaki en kullanışlı ve proje sürecinde en uygun adaptasyonu sağlayabilecek framework’leri kullanmalıdır. Kullandığı dilde piyasadaki en son gelişmeleri bilmelidir.
Örneğin ben yarım yamalak PHP bilgimle ve MySQL kullanımımla bir sistem ortaya çıkarmıştım fakat sonradan bir çok test yapmak zorunda kaldım. Kimi bug’ı kendim buldum, kimilerini de kullanıcı bildirimleri sayesinde öğrendim. Fakat yazdığım uygulama 10,000 kullanıcıda şimdiye kadar sorun çıkarmasa da aynı anda sitede gezen 50 kişi belki de kaos olacaktı. Bu yüzden eğer altyapı kodlanacaksa işin eri birinin bunu yapması gerek.
Arayüz tasarımı konusu ise başlı başına bir bela idi. Oturup uzman olmadığım XHTML, CSS, JavaScript gibi konularda bir şeyler öğrenmeye çalışarak bir arayüz çıkardım. Hala kendi yaptığım arayüzü (duygusal bağlarımdan ötürü) seviyorum, fakat bir çok tasarımcıya göre tam bir felaket. Birkaç görüntü atraksiyonu yapabilmek için harcadığım o kadar zamanın bugün bana kattığı bilgi açısından boşa gitmediğini düşünüyorum. Ben javascript kütüphanesi olarak prototype+script.aculo.us kullanıyordum fakat bugün jQuery’e eklenen ufak tefek eklentiler benim saatler verip yaptığım ve bug içeren şeyleri neredeyse sorunsuz olarak sunuyolar. Belki de o zaman jQuery’den haberdar değildim, piyasayı iyi araştırmamışım bu benim hatam. Arayüz işini de konuyu bilen yapmalıdır. Read More →
**Design Issues in Modern Programming Languages **
Ahmet Alp Balkan
This essay has been prepared for Programming Languages CS course. It can be freely used and distributed. Details of a programming language design is one the most controversial issue in the theory of programming languages. Many years ago, languages designed for programming computers have
a syntax such that only a machine can understand and translate. Such languages were called “low-level programming languages” and they were not providing any abstraction functionality while coding a new program using these languages. [1] These machine languages are evolved to assembler and many years later we have “high-level programming languages” which sometimes hide all details of computer architecture and language implementation details with abstracting many kinds of functionality. People “create” something when they do need it. With evolution of computers and computer programming, many reasons triggered creation of new programming languages. Most of the time, these reasons are about efficiency, usability, style, functionality (capability) of usage of these programming languages. Let’s say if a company hires a software engineer and request a computer program does a particular job, if engineer would code this program in assembly language, it may take months; on the other side, most probably, it would take a few days using a new-generation programming language. That is about the efficiency and saving money for enterprise market in software engineering. To do particular jobs in computers, labs or people design new programming languages which developers can get rid of unnecessary parts of implementation.
Readability and ease of coding are also reasons behind appearance of new programming languages. Recall from low-level programming languages, the first languages i.e. FORTRAN, ALGOL, COBOL were not consist on good readable codes. This is a big deal since many software is created collaborated today, the code written on a language must be readable easily by other developers as well. However, major languages designed in last 15 years consist on a syntax which is human-friendly. In this issue, it is not all about programming language design but also developers’ coding style. [2] On the other hand language syntax is exactly a limiting factor for code readability. Any code written on a language may not be readable even it has been coded by a pretty good developer. Besides that, collaboration is limited by readability. When Hejlsberg released C# language, one of the important benefit was ease of coding and readability of code.[3] Read More →
This is a unit test post for various features that should be present on my blog. Do not take it seriously, move on to my home page. Test, test, one-two-three. Here we go: This is an external link and it should be rendered as such. To be clear here is another external link with short Markdown syntax. Read More →