Mapsys normalde sistem dinamiği modelleri geliştirmek için üretilmiş bir araç. Fakat çok hızlı bir şekilde çizge (bağlantılı öğelerden oluşan bir şema) oluşturma kabiliyeti sunduğu için, bu aracı yazılım geliştirmede nesne modellemesi için de kullanmak çok pratik oluyor.
UML'in sunduğu özelliklerin çoğunu desteklemiyor, Mapsys. Bu normal, çünkü bir UML tasarım aracı değil. Fakat benim için en önemli özelliklerden biri, çok hızlı bir şekilde basit nesne çizgeleri geliştirmek. Bunu yapabilmemi sağlıyor.
Resimde oluşturduğum bir modelden örnek bir kesit gösteriyorum. UML'den biraz farklı bazı yazım standartları kullanıyorum. UML'de nesne başlıkları, "< obje_adı >:@lt class_adı >" şeklinde. Bense şu şablonu kullanıyorum: "< class_adı > @ < obje_adı >"
Bu yazım şeklinin okunabilirlik açısından bir faydası var: Bazen sadece class ismini, bazen sadece obje ismini kullanmak istiyorum. UML'de bunu yapmak mümkün, fakat görsel ayrıştırma çok kuvvetli olmuyor.
Pazartesi, Ekim 20, 2008
Pratik Bir Nesne Modelleme Araci: Mapsys
Pazartesi, Ekim 13, 2008
Yari Cevik Tasarim
Çevik süreçler genel olarak, sistemin ön tasarım ile geliştirilmesinin yerine, tasarımın test ve programlama içinden geliştirilmesini söylüyor. Bu kural genel olarak doğru bir kural. Fakat istisnaları var.
Son zamanlarda üzerinde çalıştığım iş akışı otomasyonu projesinde, farklı bir yöntem izliyorum. Önce dokümantasyon ile birlikte, sözde kod benzeri mantıksal bir tasarımı çıkarmaya çalışıyorum. Gayet verimli oluyor. Program ve testin yararı, mantıksal adımlardaki boşlukları tümüyle gidermek oluyor. Fakat ister istemez, üst seviye hızlı bakıştan biraz ödün vermek gerekiyor. Ayrıca kod bir kere yazıldıktan sonra, mevcut kod evrime engel oluyor.
Dinamik diller, type inferencing, otomatik refactoring desteği mevcut kodun evrilmesini kolaylaştırıyor; fakat yine de bu araçlarla bile değişim düşüncenin hızına yetişemiyor. Ne var ki, aklın da kapasitesi çabuk doluyor. Tasarım kararlarının sayısı belirli bir miktarın üzerine çıkınca, zihin bunları takip edemiyor.
Bu yüzden, şöyle bir yöntem izliyorum: Eğer tasarım gerektiren zor bir problem üzerine çalışıyorsam, önce sözde kodlarla mantıksal tasarımı geliştiriyorum. Aklımın kaldırabileceği kadar karmaşıklığa varınca, program ve testleri yazıyorum. Sonra bir sonraki tasarım problemi için yeniden, mantıksal tasarımı elle yapmaya geri dönüyorum. Çevik ilkelerin tavsiye ettiği gibi, bu da yine devirli bir tasarım süreci. Fakat çevik ilkelerden farkı, önce tasarım, sonra program/test.
Gerçi bu usul çok yeni bir farklılaşma da sayılmaz. Yıllardan beri çevik yöntemlerden sayılan Jeff de Luca ve Peter Coad’ın FDD (feature driven development) yöntemi de önce tasarım, sonra programlama çevrimini tavsiye ediyor.
Cuma, Eylül 26, 2008
Programming in Scala Kitap Ozeti
Bir haftadır Martin Odersky'nin Programming in Scala kitabını okuyordum. Benim alışkanlığımdır, bu tip öğretici kitapları okurken, bir yandan da Keynote programıyla tüm notlarımı tuttuğum dosyaya not alırım.
Bu kitaba ait özet notlarımı pdf haline çevirip internete koydum. İsteyen yararlanabilir.
Fakat tabi ki özet notlar kitabın yerini alamaz. Bu özet notlar, kitabı okumuş veya scala'ya hakimiyeti olan programcıların yararlanabileceği hızlı bir gözden geçirme kaynağı olabilir.
Pazartesi, Mayıs 19, 2008
Asla String kullanmayin
Stephan Schmidt Never, never, never use String in Java (or at least less often :-) makalesinde, String gibi primitifleri kullanmak yerine alternatif bir çözüm öneriyor. Yaklaşımının temelinde DDD (domain driven design) yani alan temelli tasarım yatıyor. Temel fikir şu: Alana (veya domain/business) ait kavramların nesnelerle temsil edilmesi, en küçük alan kavramından başlamalı. Bir kişinin ismi dahi kendi adına bir nesne olmalı.
Makaleden aldığım notlar burada:
String gibi primitifler kullanmayın
eski yol:
public void bookTicket(
String name,
String firstName,
String film,
int count,
String cinema);
yeni yol:
public void bookTicket(
Name name,
FirstName firstName,
Film film,
Count count,
Cinema cinema);
faydaları:
çok uzun parametre listesi alan metotlar kendi kendini dokümente ederler
iş mantığının yönetimi daha kolay olur
şeklinde yazmak işi zorlaştırmaz mı?
new Name("ahmet")
çözüm:
public static Name name(String name) {
return new Name(name);
}
böylece:
new Customer(firstName("Stephan"), name("Schmidt"));
eski yol:
new Customer("Stephan", "Schmidt");
başka örnek:
new Point(10,10);
yeni yol:
new Point(x(10), y(10));
XPos ve YPos objeleri kullanılıyor
örnek:
fiyatla arama yapmak:
searchByPrice
bu metodun argümanları nasıl olmalı?
kötü yol:
Vector searchByPrice(double start, double end)
iyi:
List
veya
List
---
Tartışma:
İtirazlar:
1. YAGNI ilkesi ihlal edilmiş olmuyor mu?
Cevaplar:
Oliver:
http://stephan.reposita.org/archives/2008/05/02/never-never-never-use-string-in-java-or-at-least-less-often/#comment-87153But we actually had a problem with the last names on the project I am currently on. The business wanted to limit the last name length to minimum 2 characters, and of course, the code was littered with length checking, from the ui level to the database.
A couple of months later, they dropped that requirement, and it took us ages to find all the checking throughout the code and remove it.
The original blog post argued that domain modeling needs to occur at the lowest possible level. At some point, every project, starts introducing domain model.
Pazar, Kasım 04, 2007
OpenSocial: Sosyal Aglar Icin Programlama Arabirimi
OpenSocial, bir programcının yazdığı bir uygulamanın tüm sosyal web sitelerinde çalışmasına yönelik bir kütüphane. Bu çok devrimci bir gelişme. Doğrudan doğruya artık geliştirilecek olan iş uygulamalarının sosyal sitelere yönelik olmasını sağlayacak.
Google tarafından yönlendirilen açık bir çalışma OpenSocial. LinkedIn, Orkut, salesforce gibi pek çok sosyal ağ, OpenSocial API'sine destek veriyor.
Temel amaç tek bir API üzerinden hem sunucu tarafındaki REST servislerine hem de istemci tarafındaki JavaScript servislerine erişim sağlamak.
OpenSocial'ın temel servisleri. OpenSocial hangi temel arabirimler üzerinden bilgi sunuyor:
People: Ben kimim, profilimde ne bilgiler var. Bu gibi bilgilere erişim sunuyor.
Arkadaşlar: kimleri tanıyorum, kimlere bağlantım var?
Aktiviteler: neler yapıyorum, kimlerle hangi bilgileri paylaşıyorum?
Kalıcılık (persistence): Sunucu gerektirmeden durum kaydetmek sağlanmalı. Burası işin en güzel yanı: OpenSocial herhangi bir sunucu gerektirmeden, veriyi kaydetme servisi sunuyor. Yani OpenSocial uygulamalarınızı kendi hostunuzda çalıştırmanız gerekmiyor.
Birkaç kod örneği:
data.getViewer().getDisplayName()
Bu kullanıcının isminin döndürülmesini sağlıyor.
Arkadaşlarını çekmek için:
data.getViewerFriends().asArray()
Yeni aktivite oluşturmak ve bunun kullanıcının haber listesinde görünmesi için:
newRequestActivity
OpenSocial kullanarak, sosyal ağ sitesinin kendi mühendisleri kadar derin bilgiye ulaşmak mümkün.
Orkut, google'ın sosyal ağı, bir deneme tahtası (sandbox) sunuyor, opensocial uygulamaları için.
Cumartesi, Temmuz 21, 2007
Programlama Kitap ve Makale Ozetleri
Çeşitli programlama kitap ve makalelerine dair aldığım notların linkleri:
Martin Fowler, Refactoring:
http://writer.zoho.com/public/mnuhoglu/Refactoring1
Çok iyi bir kitap. Sade, okunaklı ve kolay anlaşılır program yazmakla ilgili.
Dave Thomas, Programming Ruby:
http://writer.zoho.com/public/mnuhoglu/Programming-Ruby1
Dave Thomas çok iyi bir yazar. Ruby çok güzel bir dil. Fakat ben hala statik dillerde kendimi daha rahat hissediyorum.
James Gosling, Effective Java Programming
http://docs.google.com/Doc?id=a7w6zmv5z8j_30fxhqgd
Çok iyi bir kitap. Java ile programlamaya dair çok önemli kurallar.
Martin Fowler, Enterprise Application Architecture
http://docs.google.com/Doc?id=a7w6zmv5z8j_29gv9bbc
Kurumsal yazılımlarda kullanılması tavsiye edilen mimari çözümlerle ilgili çok iyi bir kitap. Kitapta anlatılan çözümlerin pek çoğu, zaten programcıların kullandığı çerçeveler tarafından otomatik olarak yürütülüyor. Ama yine de altta ne yattığını öğrenmek açısından faydalı bir kitap.
Alistair Cockburn, Writing Effective Use Cases
http://docs.google.com/View?docid=a7w6zmv5z8j_13db45zs
Gereksinim analizi konusunda, gerçekten çok iyi bir kitap bu. Kullanım senaryoları (use case) konusunu çok iyi anlatıyor.
Glenn Meyer, The Art of Software Testing
http://docs.google.com/Doc?docid=a7w6zmv5z8j_17g2rb6d&hl=en
Kent Beck, Test Driven Development
http://docs.google.com/Doc?docid=a7w6zmv5z8j_18cwpmpf&hl=en
Yazılım geliştirme sahasında çığır açıcı kitaplardan biri. Şimdi çok popüler bir konu olan TDD'nin öncü eserlerinden.
Steven John Metsker, Building Parsers with Java
http://docs.google.com/Doc?docid=a7w6zmv5z8j_33gzkkj9&hl=en
Eric Evans, Domain Driven Design
http://docs.google.com/Doc?docid=a7w6zmv5z8j_31djc5sg&hl=en
DDD yazılım tasarımıyla ilgili çok yararlı bir yaklaşım. Çok atıf alan bir eser.
Kent Beck, Extreme Programming
http://docs.google.com/Doc?docid=a7w6zmv5z8j_28hd97w6&hl=en
XP metodolojisinin piyasaya sunulduğu ilk kitap. XP'nin geliştiricisinden.
Herrington, Code Generation in Action
http://docs.google.com/Doc?docid=a7w6zmv5z8j_323z72bk&hl=en
Güzel bir kitap, fakat pek kullanmadığımdan ne kadar yararlı bilemiyorum...
Bauer ve King, Hibernate in Action
http://docs.google.com/Doc?docid=a7w6zmv5z8j_27hrhrbn&hl=en
Hibernate kütüphanesinin geliştiricilerinden bir eser. Hibernate java ve .net platformlarında çok kullanılan bir veritabanı-nesne eşleştirme mekanizmasıdır...
Dave Thomas, Pragmatic Programmer
http://docs.google.com/Doc?docid=a7w6zmv5z8j_238b685p&hl=en
Bu kitabın tarzını çok seviyorum. Sohbet şeklinde, ama çok değerli tavsiyeler içeren bir kitap. Sanki usta bir programcının yanında, programcılığı öğrenmek gibi bir his bırakmıştı bende...
Hibernate Reference
http://docs.google.com/Doc?docid=a7w6zmv5z8j_264qdgb3&hl=en
Hibernate kütüphanesinin resmi kılavuzundan aldığım notlar
Suzanne Robertson, Mastering The Requirements Process
http://docs.google.com/Doc?docid=a7w6zmv5z8j_25dws79k&hl=en
Gereksinim analiz sürecini bu kadar iyi anlatan pek fazla kitap olmadığını düşünüyorum. Çok iyi, hem teorik hem de pratik yönleri olan bir kitap.
SQL in a Nutshell
http://docs.google.com/Doc?docid=a7w6zmv5z8j_20df85qt&hl=en
SQL konusunda hızlı bir referans kitabı
Teach Yourself HTML and CSS in 24 Hours
http://docs.google.com/Doc?docid=a7w6zmv5z8j_19p6v554&hl=en
Alan Cooper, About Face
http://docs.google.com/Doc?docid=a7w6zmv5z8j_15d9bh99&hl=en
Bu eser, kullanıcı arayüzü tasarımı konusundaki en iyi kitaplardan biri olarak gösteriliyor.
Barry Boehm, Balancing Agility and Discipline - A Guide for the Perplexed
http://docs.google.com/Doc?docid=a7w6zmv5z8j_14m3cdpn&hl=en
Metodolojilerle ilgili yaklaşımı çok iyi dengeleyen bir kitap.
Makaleler:
Bu dosyaları pdf olarak box.net'e koymuştum:
ArsDigita:
http://www.box.net/shared/static/m6hxpqmuqv.pdf
Çok iyi bir hikaye. Amerika'daki venture capital mekanizmasının başarılı bir startup firmayı nasıl iflasa sürüklediğini anlatıyor.
Aşamalı Geliştirme (Iterative Development)
http://www.box.net/shared/static/4mmrifni30.pdf
AOP (aspect oriented programming)
http://www.box.net/shared/static/2f2pcp00t4.pdf
BlackMamba: A Swing Case Study
http://www.box.net/shared/static/8qa8ebyigz.pdf
Swing ile yazılım geliştirmeye dair örnek bir uygulama mimarisi...
Data Access with the Spring Framework
http://www.box.net/shared/static/734gjvkyz9.pdf
Eşli Programlama (Pair Programming)
http://www.box.net/shared/static/mb6kgkv1vc.pdf
Exploratory Testing Explained
http://www.box.net/shared/static/416042nqeu.pdf
Cockburn, In Search Of Methodology
http://www.box.net/shared/static/oiiclxxr67.pdf
Joel On Software
http://www.box.net/shared/static/i2vb271uvg.pdf
Joel'in eski yazıları, yazılım geliştirme konusundaki en güzel denemelerden...
Cockburn, Kahve Makinesi
http://www.box.net/shared/static/pullc94o0x.pdf
Nesne odaklı geliştirmeye yönelik güzel bir vaka çalışması.
Paul Graham'ın yazıları
http://www.box.net/shared/static/c55iszibcf.pdf
Paul Graham'ın çok hoş bir yazım tarzı var.
Rethinking Swing Threading
http://www.box.net/shared/static/4mp8k8odri.pdf
Using the Jakarta Commons
http://www.box.net/shared/static/i72y4b8rp1.pdf
Why Functional Programming Matters
http://www.box.net/shared/static/4j0zjorxyl.pdf
Diğerleri:
http://writer.zoho.com/public/mnuhoglu/Diger-Teknik-Kitap-ve-Makaleler1
box.net'teki klasörüme erişmek için:
http://www.box.net/shared/rfdpnqgol9
Cumartesi, Nisan 21, 2007
Karakter Kodlama Terimleri
Karakter kodlamasıyla ilgili kavramlar, oldum olası bana karışık gelmiştir. Bugün nihayet bu karmaşaya son vermek için, kısa bir araştırma yaptım. Burada bazı notlarımı yazıyorum:
character reference (character escape)
numeric character reference
&#DD (decimal)
&#xHHHH (hexadecimal)
character entity reference (named entities, html entities)
<
>
character encoding
Numerik referanslar, unicode tarafından tanımlanan UCS (universal character set) rakamlarına sadıktır.
Eğer utf-8 gibi yerli bir unicode kodlaması kullanılırsa o zaman, karakter referanslarına hiç gerek kalmaz.
Yani karakter referansları, aslında unicode karakterleri, ascii formatında uzun uzun yazmaktan ibaret. Unicode yazınca o zaman bu karakterler, ascii formatında değil, doğrudan binary formatta kaydediliyor.
Faydalı linkleri delicious hesabımda topluyorum: http://del.icio.us/mnuhoglu/character-maps
Pazartesi, Mart 20, 2006
Program Yazma Keyfi
Programcılık neden bilmiyorum bana çok büyük bir keyif veriyor. Bir problemi ele almak. Onu anlamaya çalışmak. Çözümler tasarlamak. Buna yönelik bir ilerleme planı oluşturmak. İlk adımı tasarlamak ve bunu uygulamak. Biraz ilerlemek. Sonra plana geri dönüp kaldığım yerden devam etmek... Bunlar bana büyük keyif veriyor. Gerçi her zaman böyle olmuyor. Belki çoğu zaman problemlerde tıkanıyorum. Ama sonra sabırla uğraşmaya devam etmek ve bir şekilde tıkanıklıkları aşmanın verdiği sevinç bir başka oluyor.
Bazen bir arkadaşıma bildiğim şeyleri anlatmaktan da çok keyif alıyorum. Ona anlatırken kafamda problemler ve çözümler daha güzel oturuyor. Sonra bana karşılaştığı problemler için danışmaya geliyor. Genelde o aşamalardan daha önce geçtiğim için, çoğunu bir şekilde yanıtlayamıyorum. Ama her zaman da böyle olmuyor.
Üniversitede endüstri mühendisliği okudum. Onu da seviyorum, ama programlama yapmak bana daha çok keyif veriyor. Çünkü üniversitede gördüğümüz derslerde bu kadar çok mühendislik problemiyle karşılaşmıyorduk. Daha büyük çaplı ancak daha az sayıda problem oluyordu. Fazla formül ağırlıklı çalışıyorduk ve mantığını bilmesek de formülleri uygulamakla problemleri çözebiliyorduk. O zaman da problemlerle uğraşmanın keyifini yaşayamıyorduk. Gerçi her zaman da böyle değildi. Bazı zamanlar çok keyif veren problemlerle de uğraşıyorduk... Son sene aldığım vaka çalışması (case study) içeren dersler böyleydi. Bir de tabi favori dersim: Sistem Dinamikleri dersi vardı.
Şimdi endüstri mühendisliğini tekrar okusaydım, öğrendiğim tüm modellerin mantığını daha iyi anlamak için özel gayret sarf ederdim. Neden bunu okurken yapmadım, acaba? Galiba insan okurken, derslere düşman olmaya kendi kendini programlıyor. Bir şey ancak ders dışı olursa, onu severek yapma isteği oluşuyor :)
Pazartesi, Ocak 16, 2006
Metodoloji Arayışı - In Search Of Methodology
Cockburn'den yaptığım özetlere çok beğendiğim bir makalesiyle devam edeceğim: In Search of Methodology:
IBM´in metodoloji danışmanlığı grubu OO metodolojileri araştırdı.
Çok sayıdaki OO metodolojisinden hangisini kullanmalıyız, sorusu yerine, bir OO metodolojisinin hangi unsurunu kullanmalıyız? Kabullenmeyi etkileyen şey nedir? Çeşitli yöntemlerin güzel özelliklerini nasıl entegre edebiliriz?
OO çok popülerleşti. Ancak uygulayıcıların çoğunun acemi oluşundan dolayı, yeterli bir olgunluk oluşmadı.
Bir metodolojinin kullanılabilir olması şu özelliklere bağlı:
Basit, etkili ve düşük iş yükü oluşturması. Kabullenme ve kullanışlılık, grubun iş alışkanlıklarını değiştirme yeteneğine bağlı. Ayrıca bürokratik işlere olan toleransına bağlı. Her ikisi de düşüktür. Mühendislik kökenli gruplarda daha yüksek.
Dizayn tekniklerinin faydalı olması için karmaşık olması gerekmiyor. En çok kullanılan ve fayda sağlayan iki teknik: Use caseler ve sorumluluklar. Bunlar aşamalı geliştirme (incremental development) ile de uyumlu. Ayrıca dizayn kalıpları gibi yeni fikirler için alan bırakıyorlar.
Araştırma bulguları:
- Geliştiriciler, doğrudan son ürüne yönelmemiş dizayn etkinliklerine zaman harcamak istemiyorlar.
- Elle (manuel) dizayn dokümanlarının güncellenmesi işinden hoşlanmıyor. Bunu yapmıyorlar.
- Yeni iş alışkanlıklarını öğrenmek için sınırlı zaman veriliyor.
- Geliştiriciler metodolojinin sevmedikleri yönlerini genellikle uygulamıyorlar.
Bürokratik işlerden kaçınılıyor. Bunun sebebi geliştiricilerin bu konuda yetkiye sahip olmaları. Veya değilse bile organizasyonun metodolojinin bu yönlerinin uygulanıp uygulanmadığını takip edememeleri. Proje yöneticisi de çoğu zaman metodolojinin yıkıldığının farkında değil.
Basit yöntemler:
Yukarıdaki sorunlar olmakla birlikte, iyi geliştirciler iyi sistemler tasarlamaya devam ediyor. Bunlarla yapılan görüşmeler, bunların basit, etkili ve verimli teknikleri tutarlı olarak yürüttüklerini gösteriyor.
Sorumluluk:
Sorumluluk temelli tasarımın en çok kullanılan ve etkili bir dizayn tekniği olduğu ortaya çıktı.
Sorumluluk sistem tasarımının gerekçesini oluşturur. Ancak yapısal tasarımda da sorumluluk kavramı vardı. Fark ne?
Nesne tasarımında sorumluluklar aynı zamanda hem tanımlanır hem de dağıtılır. Yapısal analizde tanımlanır ancak dağıtılmaz.
Ancak herkes sorumlulukların bulunup dağıtılması işini aynı kalitede yapmaz.
Yeni gelenler bile hemen bu işten dolayı ya bir rahatlık ya da bir rahatsızlık hissi alıyor.
Use case:
Sorumluluklar bir nesnenin veya alt sistemin bir fonksiyonu nasıl gerçekleştirdiğini gösterir. Ama niçini göstermez. Bunu senaryolar ve use caseler sağlar.
Use Case nedir?
Sistemle aktör arasındaki bir işlem diyaloğu...
Bu tanımda maksat eksik. Niçin?
Jacobson yeni yazılarında, daha kaba işlem ve senaryo seçiminin daha inceltilmiş seçimlerden daha faydalı olduğunu söylüyor.
Bir teyp cihazını düşünelim. Her bir İleri Sar, Play, Geri Sar düğmesi bir use case olabilir. Veya...
"Bu düğmelere niye basıyoruz?"
"Kasette belirli bir yeri bulmak için."
Öyleyse tek tek düğmeler değil, düğmelerin belirli bir kombinasyonu aslında bir use case. Veya şöyle diyelim: "Kasette belirli bir yeri bulmak için basıyoruz."
Use case, bir "kullanım zarfıdır". Zarfın kapağında, maksadı yazar. İçindeyse, bu maksadın nasıl gerçekleştiği, bu da başka use caseler, senaryolar ve kullanım zarflarıyla olur.
Use caselerin maksatlarının toplamı, bir sistemin ihtiyaçlarının en kısa ve okunabilir tarifidir.
Devirli geliştirme (iterative development):
Yapılan görüşmeler şunu gösterdi. Devirli geliştirme, projenin başarılı olup olmayacağının çok iyi bir ayırt edicisidir. Çok az yönetici bunun mantığını ve mekaniğini anlamış.
Niçin böyle?
Birinci sebep, aşamalı geliştirme, proje yöneticilerinin çalışma alışkanlıklarını etkiliyor. Halbuki bu insanların, değişme becerileri geliştiricilerden daha yüksek değil.
İkinci sebep, aşamalı geliştirme için karmaşık ve muğlak tanımlar kullanılmış. Spiral, küp, "gestalt round trip"... Bunların yerine daha basit tarifler gerekiyor.
Pazar, Ocak 15, 2006
Yeni Groovy
Yazılım dünyasının en güzel özelliklerinden biri, birkaç ay kendisinden uzak kaldığınızda, size pek çok yeni ürünler göstermesi... Bir süredir gerek işte uğraştığımız projelerden, gerek de akşamleyin farklı alanlarla ilgileniyor olmamdan dolayı, java dünyasındaki yenilikleri takip edemiyordum. Bugün biraz internette dolaştım, java.net, clientjava.com ve diğer popüler sitelerdeki geçmiş blogları takip ettim. Özellikle groovy ve netbeans beni çok etkiledi. Kendim yazılım geliştirirken, IntelliJ'i kullanıyorum. IntelliJ pek çok açıdan bütün diğer IDE'lerden daha fazla verimlilik kazandıran özelliğe sahip. Ama yine de Netbeans'in özellikle Matisse adlı GUI tasarımı için kullanılan modülü harika. IntelliJ'de veya şu ana gördüğüm diğer GUI tasarım araçlarından çok daha kullanışlı ve özellikli.
Bu arada, java.net'te birinin yazısını okuyordum. Microsoft'un pazarlama yöneticilerinden biri yeni VS'deki Rename ve IntelliSense özelliklerinin çok büyük yenilikler olduğunu söylüyormuş. Halbuki bunlar Eclipse, IntelliJ gibi java IDE'lerinin artık yıllar önce geride bıraktıkları standart özellikler. MS dünyasını doğrudan gözlemleyemiyorum. Çalıştığım yerde herkes java üzerinde çalışıyor. Evde de MS'in ürünlerini yüklemedim. Ancak dolaylı yollardan öğrendiklerim kadarıyla Java platformu, MS'den hem görsel tasarımda, hem de yenilikçi IDE özelliklerinde birkaç sene daha önde.
İki sene önce Petran/MedArt firmasında çalışırken yöneticilerimizden biri -Ömer Oruç- çok güzel bir söz söylemişti. Tam olarak dediklerini hatırlayamıyorum, ama yaklaşık şu anlama geliyordu: Uzun vadede, açık platformlar, kapalı platformlara göre üstünlük sağlar. Çünkü açık platformlar, çok daha fazla insanın katkısıyla gelişir.
Java dünyasındaki çok sayıdaki yenilikten biri de Groovy. Daha önce Ruby on Rails ile ilgili izlenimlerimi birkaç defa yazmıştım. Groovy, Ruby'nin güzel yönlerini java ortamında yapmaya izin veren bir ortam. Ortam diyorum, çünkü içinde yeni bir programlama dili, bir MVC web framework, debug etmeyi kolaylaştıran bir konsol, COM objelerini scriptle programlamayı sağlayan bir kütüphane gibi çok sayıda teknolojiyi barındırıyor. Umarım yeterince yazılım geliştirici tarafından Groovy kullanılır ki, zaman içinde daha da fazla gelişebilsin.
Çarşamba, Aralık 28, 2005
Structure and Interpretation of Computer Programs, Video Lectures
Bu sitedeki videolar gerçekten harika... "Structure and Interpretation of Computer Programs" adlı kitabın yazarları olan iki MIT hocasının 1986'da verdiği derslerin tümünün video kayıtlarını bu sayfadan indirebilirsiniz.
Hocalar meşhur LISP programlama dili üzerinden programlamanın teorisini anlatıyorlar. İlk dersi izledim. Çok güzeldi. Hem anlatım şekli çok iyi, hem de içerik çok faydalı. LISP'i uzun zamandır merak ediyordum. Özellikle de Yahoo'nun ortaklarından Paul Graham'ın web sitesindeki makaleleri okumak, bende merak uyandırıyordu. Bir kitaptan da LISP öğrenmek mümkün, ama dünyanın en iyi hocalarından ikisini yemek yiyerek dinlemek, çok daha rahat :)
Dersin başından ilgimi çeken bir noktayı da sizinle paylaşayım. Hoca dersin başında büyük harflerle tahtaya COMPUTER SCIENCE (Bilgisayar Bilimi) yazıyor ve ekliyor: "Bu ders bilgisayar bilimini tanıtıyor. Ancak bizim yaptığımız iş, ne bir bilimdir, ne de bilgisayarlar üzerinedir."
Aslında biraz düşününce, hocaya hak vermemek mümkün değil. Bilgisayar bir araçtır. Bilgisayar, programlamanın aracıdır, yoksa konusu değil. Programlama bir bilim olmaktan ziyade, bir sanat veya mühendisliktir. Çünkü objektif doğrular yoktur.
Salı, Aralık 27, 2005
Rubyye Sorularim 1
Şu ana değin, hep Ruby'nin parıltılarını anlatıyordum. Bu sefer bir değişiklik yapacağım. Ruby'yle ilgili bir sorumu, hatta pek de hoşuma gitmeyen bir noktayı yazacağım. Nesne odaklı programlamayla ilgili kurallardan biri, değer nesnelerinin (value objects - ancak bu kavramı J2EE Design Patterns'ın value object patternıyla karıştırmayın, o farklı bir şey) bir kere oluşturulduktan sonra değiştirilmemesi (immutable) gerekir. Bunu temin etmek için, Java String, Integer gibi en çok kullanılan değer nesnelerini değiştirilmez kılmıştır.
Ancak gördüğüm kadarıyla Ruby'de böyle bir durum yok. Değer nesnelerini değiştirebiliyorsunuz....
Rubyde:
x = "merhaba"
x.upcase!
puts x
=>
"MERHABA"
Javada:
String x = "merhaba";
String y = x.toUpperCase();
System.out.println("x = " + x);
System.out.println("y = " + y);
=>
x = merhaba
y = MERHABA
Neden böyle yapmışlar acaba?
Pazartesi, Aralık 26, 2005
Rubyden Parıltılar 2 - Bloklar
Rubynin (sanırım Groovy, Python, Smalltalk gibi diğer OO dinamik dillerde de mevcut) çarpıcı özelliklerinden biri de bloklar. Aşağıda fibanacci sayılarını hesaplayan ve bunları konsola yazan bir kod parçası var:
def fib_up_to(max)
i1, i2 = 1, 1 # parallel assignment (i1 = 1 and i2 = 1)
while i1 <= max
yield i1
i1, i2 = i2, i1+i2
end
end
fib_up_to(1000) {|f| print f, " " }
Yukarıda blokların kullanımına bir örnek var. {|f| print f, " " } bir blok. fib_up_to metoduna -bir tür parametre olarak- bu blok gönderiliyor. yield ile metodun içinden, blok çağrılıyor.
Yukarıdaki kodun güzelliği farklı iki sorumluluğun çok net ve kolay bir şekilde birbirinden ayrıştırılmış olması (seperation of concerns). Blok, kendisine gönderilen bir nesneyi konsola yazdırmakla ilgileniyor. Metot fibonacci algoritmasıyla ilgileniyor. Her ikisi de birbirinin davranışlarından tümüyle bağımsız (orthogonal). Ancak ikisi birlikte kolaylıkla işbirliği yapabiliyor.
Bu örnek için şunu diyebilirsiniz, konsola bir değer yazdırmak için, bunu blokta yürütmenin ne faydası var? Doğrudan while döngüsünün içine bu satırı yazsak, daha basit ve hızlı olurdu.
Sadece bu örnek için bu iddia doğru. Ancak düşünün ki, fibonacci algoritmasını yeri geldikçe farklı ortamlarda kullanmanız gerekebilir. Bir yerde fibanacci dizisini veritabanına yazdırabilirsiniz, bir yerde bunu bir GUI'ye koyarsınız. Veya bu dizinin elemanlarıyla yeni matematiksel işlemler yapmanız gerekebilir. Bu gibi farklı ihtiyaçlar için, yukarıdaki metodu hiç değiştirmeniz gerekmez. Sadece metodun birlikte çalışacağı bloku yazmanız yeterli. Böylece fibanacci dizisini oluşturma mantığını sadece tek bir yerde yürütürsünüz (Don't Repeat Yourself - DRY).
Pazar, Aralık 25, 2005
Türkçe Karakter Problemleri
Java üzerinde geliştirilen yabancı frameworklerde en çok rastladığım problem, "i" harfinden kaynaklanıyor. Yabancılar, java ile geliştirme yaparken, String.toLowerCase ve String.toUpperCase metotlarını direkt kullanıyorlar. Bilmiyorlar ki, bizim dilimizde, bu metotlar kendi dillerindekinden farklı çalışıyor. En son olarak JEdit'in 4.2 versiyonunda ve Jakarta Commons NET kütüphanelerinde bu sorunu fark ettim. Geliştiricilerine sorunu ve çözümü bildirdim...
"i".toUpperCase() metodu, Türkçe bilgisayarlarda, "İ" Stringini üretir. Bu da çoğu zaman uygulamanın beklendiği gibi çalışmamasına sebep olur.
Sorunu düzeltmek için, "i".toUpperCase(Locale.ENGLISH) şeklinde metodu kullanmak gerekir.
Bu tarz problemleri kolay bir şekilde tespit etmek için, şu main metodunu kullanabilirsiniz:
public class Main2 {
public static void main(String[] args) {
Locale.setDefault(new Locale("tr","TR"));
org.gjt.sp.jedit.jEdit.main(args);
}
}
jEdit yerine, hangi kütüphaneyi kullanıyorsunuz, onu koyun. Bir bu şekilde çalıştırın, bir de Locale.setDefault(Locale.ENGLISH); ile çalıştırın. Eğer sorun çıkıyorsa, büyük/küçük harf dönüşümü sırasında sorun oluyor demektir.
Kayıtlar
