Acaba Bazı Organizasyonlar Çalışma Şekillerinin Verimsizliğini Gördükleri Halde Neden Aynı Şekilde Çalışmaya Devam Ederler ?

The Monkey Experiment, (or) “Why Do We Do That?”

Start with a cage containing five monkeys. Inside the cage, hang a banana on a string and place a set of stairs under it. Before long, a monkey will go to the stairs and start to climb towards the banana. As soon as he touches the stairs, all of the other monkeys are sprayed with cold water. After a while, another monkey makes an attempt with the same result, and all the other monkeys are sprayed with cold water. Pretty soon the monkeys will try to prevent it.

Now, put away the cold water. Remove one monkey from the cage and replace it with a new one. The new monkey sees the banana and wants to climb the stairs. To his surprise and horror, all the other monkeys attack him. After another attempt and attack, he knows that if he tries to climb the stairs he will be attacked.

Next, remove another of the original five monkeys and replace it with a new one. The newcomer goes to the stairs and is attacked. The previous newcomer takes part in the punishment with enthusiasm! Likewise, replace a third original monkey with a new one, then a fourth, then the fifth.

Every time the newest monkey takes to the stairs, he is attacked. Most of the monkeys that are beating him have no idea why they were not permitted to climb the stairs or why they are participating in the beating of the newest monkey. After replacing all the original monkeys, none of the remaining monkeys have ever been sprayed with cold water. Nevertheless, no monkey ever again approaches the stairs to try for the banana.

Why not? Because as far as they know, that’s the way it’s always been done around there.

Kaynak: Cenk Çivici'nin 1 Ağustos 2008 tarihinde Yazılım Mühendisliği Türkiye grubuna attığı mailden alınmıştır. Orijinal kaynak: http://www.safetycenter.navy.mil/Articles/a-m/monkeys.htm

Ustalardan İnciler

Your programming tools don’t have to determine how you think about programming (1981).

-David Gries

If your language lacks constructs that you want to use or is prone to other kinds of problems, try to compensate for them. Invent your own coding conventions, standards, class libraries, and other augmentations.

-Steven C. McConnell

Goal arbitration is essentially an algorithmic process defined by a handful of numbers. As a result, it is not driven by logic (like an FSM) but by data. This is hugely advantageous because all you have to do to change the behavior is tweak the numbers, which you may prefer to keep in a script file so that other members of your team can easily experiment with them.

-Mat Buckland (Programming Game AI by Example)

There are two ways of constructing a software design: One way is to make it so simple that
there are obviously no deficiencies and the other is to make it so complicated that there are
no obvious deficiencies.

-C.A.R. Hoare

Kod Optimizasyonu Hakkında Bazı Görüşler

The First Rule of Program Optimization: Don't do it.
—Michael A. Jackson

The Second Rule of Program Optimization—for experts only: Don't do it yet.
—Michael A. Jackson

Premature optimization is the root of all evil (or at least most of it) in programming.
— Donald E. Knuth

A fast program is just as important as a correct one—false!
—Steve McConnell

Optimizations always bust things, because all optimizations are, in the long haul, a form of cheating, and cheaters eventually get caught.
— Larry Wall

The key to performance is elegance, not battalions of special cases. The terrible temptation to tweak should be resisted unless the payoff is really noticeable.
— Jon L. Bentley and M. Douglas McIlroy

More computing sins are committed in the name of efficiency than for any other single reason—including blind stupidity.
— William A. Wulf

Improved efficiency comes at the cost of practically every other desirable product attribute.
— Martin Carroll and Margaret Ellis

When the "efficiency" programmers had trouble, they were loath to change their approach because they would then have to sacrifice some efficiency.
—Gerald M. Weinberg

Do not strive to write fast programs—strive to write good ones.
— Joshua Bloch

Game Programming Wisdom

Here are some hints for game programming:

• You have lots of alternatives to implement AI to your game. Some of them complex and academic and some of them practical. If you are programming a game than you should not use neural networks or genetic algorithms. Not only their programming but also test and debug is very hard.
• Faced with tight schedules and minimal resources, the game AI community has eagerly ambraced rules-based systems as the easisest type of AI to create, understand and debug.
• Winning, losing and losing well: An AI that wins( or loses) most of the time is fairly easy to develop. Most games can vary the number and quality of opponents to affect the desired end. In an RTS, for example, army size and rock-paper-scissors adjustments can mean the difference between victory and defeat. In an FPS or sports simulation, accuracy and speed of opponents can be adjusted. The real issue in these cases in the believability of the opponent. Huge armies early in the game in an RTS are not possible without obvious cheating. Massive waves of enemies in an FPS tend to point to a lack of attention to AI.
• Making characters intelligent is a real problem. Instead of trying to make them intelligent, Will Wright, in The Sims, solved the real problem (intelligent behavior) by turning the second one ( identifying and locating) around. What he called "smart terrain" made it far easier for the Sims to get what they needed. Smart terrain is the idea that objects on the terrain broadcast what they offer to any Sims that might be passing by. The Sims do not identify these objects on the terrain; they instead listen to what the terrain is telling them. The attractiveness of the objects that meet the current needs of a Sim cause the Sim to move toward them. For example, a refrigerator might broadcast the fact that it can satisfy the "hunger" need. If a Sim is getting hungry and walks within the influence of the refrigerator, the Sims might decide to fulfill his hunger need with that object.
• Game AI programmers should live by the K.I.S.S plan, and Keep It Simple Stupid! AI systems should allow designers and programmers to do the complex things with simple parts; parts that are easy to comprehend, reuse, debug, and mantain. Simple parts have a better chance of surviving the inevitable code changes required as the game design evolves.
• Every AI system should check for success conditions within a reasonable amount of time. If these conditions are not met, the AI should give up and try something else. At a minimum, an agent can fall back to interesting idle animations that express the agent's confusion or frustration. If enough processing power is available, the agent can reevaluate its situation and formulate a new plan.
• Create variety through the data, not through the code.

references: AI Game Programming Wisdom

Motion Detection

Finding background image by erasing moving objects...
Finding moving objects and drawing rectangles around them...

Motion detection is one of the most challenging and also the most exciting working area of computer vision. The most important point in motion detection is finding background image correctly.
If you find it truly than you can catch all moving objects easily. If you can't, then your program crates new moving objects by itself and makes you mad. (I know how it is:))
To find background image you should use voting system. What is voting system?
Voting system is giving vote to pixels which you think that can be part of background.
In my algorithm, program compares each image in order and finds same pixels. If these pixels are also in background image, it increases their vote by one. If they are not in background image then decreases each pixels' vote by one. If any pixel's vote becomes zero it changes background pixel with image's related pixel.
This method is working pretty good and quite successful for eliminating even slow moving objects.
I wrote a motion detection program in matlab by using this method. Before show you some images generated by my program; here are some hints:

• use a median filter to eliminate noise created by cameras.
• use object size filter to eliminate very small moving objects which causes mesh only.
• work on grayscale images. This decreases your work. My all background images are grayscale. But after I found background, I showed moving objects on RGB images.

Here are some images:

The Seven Da Vincian Principles

1. Curiositá:An insatiably curious approach to life and an unrelenting quest for continuous learning.
2. Dimostrazione: A commitment to test knowledge through experience,persistance,and a willingness to learn from mistakes.
3. Sensazione:The continual refinement of the senses,especially sight,as the means to enliven experience.
4. Sfumato:(Literally "Going up in smoke")A willingness to embrace ambiguity,paradox,and uncertainty.
5. Arte/Scienza:The development of the balance between science and art,logic and imagination."Whole-Brain" thinking.
6. Corporalita:The cultivation of grace,ambidexterity,fitness,and poise.
7. Connessione:A recognition of and appreciation for the interconnectedness of all things and phenomena.Systems thinking.

Yaşam Biçimi: Bilgisayar Mühendisliği

Programcılıkta sabahlamanın verdiği huzur ve tatmin çok meşhur. Programcılar sabaha kadar çalışma konusunda herkesi şaşırtan derecede istekli ve beceriklidir. Bu gece çalışması boyunca beyin bir"akış" yakalayarak saatlerin su gibi geçtiği bir çalışma ortamı oluşur. Bu çalışma sırasında beyin en derin konsantrasyon düzeylerine erişir ve genellikle zor programlar bu kesintisiz, onlarca saat süren çalışmalarda ortaya çıkar. Beyin bu stilde çalışırken kişilerin mutlu oldukları, mutluluk düzeylerinin arttığı bilimsel çalışmalarla gözlemlenmiştir. Bu çalışmalar eski Chicago Üniversitesi Psikoloji BölümBaşkanı Mihaly Csikszentmihalyi tarafından yapılmıştır.
Çalışmalarda çeşitli disiplinlerden yüzlerce kişinin günlük uğraşları incelenmiş ve bu sırada "mutluluk" düzeyleri gözlemlenmiştir. Bu çalışmaların programcılar tarafındaki bulguları ise ilginçtir. Her ne kadar programcılık bir bilim dalı(Computer Science), bir mühendislik (SoftwareEngineering) olarak düşünülse de programcıların beyninin sanatçıların çalışma stiline sahip olduğu ortaya çıkmıştır. Programcılık sırasında beyin bir"akış" moduna geçmekte, etraftan ilişkisini kesmekte ve bir probleme günlerce konstantre olabilmektedir.Başarılı programcıların çoğu konsantrasyon yetenekleri ile çevrelerini şaşırtır. Saatlerce sıkılmadan bir ekran başında vakit harcayabilirler. Bu saatler birçok kez günlere kadar uzayabilir. Yaşamsal faaliyetlerdışında hemen hemen her şeyden izolasyon gereklidir.Microsoft'ta Office yazılım geliştirme ekibinden bir programcının kendini odasına kilitleyip "bitmeden çıkmayacağım" demesi, Bill Gates'e bile kapıyı açmaması meşhurdur. Bu olay daha sonra DouglasCoupland'ın Microserfs (1996) kitabına konu olmuştur.Bu sırada kendini odaya kilitleyen programcının arkadaşlarının süper marketten gidip yassı yiyecekler alması ve kapının altından odaya atmaları, programcılar arasındaki dayanışmanın güzel ve sevimli bir örneği. Bu çalışma sırasında programcı en derin düşüne moduna geçer ve etraftan kendini izole etmeye çalışır. Birçok programcı bu amaçla müziği kullanır. Ancak müziğin programcılık sırasında beyne olan etkileri üzerine yapılan çalışmaların bulguları şaşırtıcıdır. Kreatif programlama ile müzik dinleme sırasında kullanılan beyin bölgesi aynıdır. Beyin bir müziğe konsantre olmuşken çok derin programcılık yapılamıyor. Yada yeteri kadar iyi yapılamıyor. Programcının müziği kapatınca etraftaki gürültünün etkisi ile müziği dinlediğinde beynin gerekli bölgesinin meşgul edilmesi arasında bir tercih yapması gerekir. Tahminen bu nedenle izolasyon amaçlı müzik kullanımında elektronik müziğin, hard rock, alternatif rock ve heavy metal gibi müzik türlerinin daha fazla tercih edildiği görülür. Müzik, beyin ve programcılar üzerinde çalışmalar halen sürüyor, bu derin konu araştırılmaya devam ediyor. Şu anki bulgular, kritik kodların geliştirilmesi ve müzik dinleme sırasında kullanılan beyin bölgelerinin aynı olduğunu gösteriyor. Monoton kodlama (maintenance) diyebileceğimiz program geliştirme kısmı ise beynin başka bir bölümünde gerçekleşir. Bu tür kodların geliştirilmesi sırasında müziğin programlamaya herhangi bir negatif etkisi görülmemiştir. Programcının kritik kodları yazmak için ihtiyaç duyduğu "akış" modunu koruyabilmesi için izolasyona ihtiyacı bulunur. Bu izolasyon arttıkça çalışma derinleşir, ilk önce beyinde yazılmak istenen programın çatısı oluşur, problem önce beyinde çözülür, daha sonra beyinde çözülen bu problem koda çevrilir.Programcının beyni pencereden dışarıyı seyrederken yada gözler sabit bir yere bakıp dalıp gittiği zaman bu problem çözülmeye çalışılır. Hatta programcının beyni bu problemi uyurken, araba sürerken ve diğer başka monoton işleri yaparken ele almaya devam eder. Bu durumda sıfırdan ve baştan yazılan bir programa bakıldığında kodlama toplam sürenin oldukça az bir bölümünü almaktadır.Bu çalışma sırasında beyin son derece karmaşık bir aktivite içerisine girmiştir. Var olmayan bir çözümü oluşturmak için "kreatif" süreç başlamıştır. Bu süreç duyu organlarını izole etmiş ve yaratıcılığa yoğunlaşmıştır. Bu süreç sırasında programcı onlarca konuda karar vermektedir. Değişken isimlerinden, akış yöntemlerine, parametrelerin cinsinden, kullanıcı arabirimine kadar bir programcı sürekli bir "karar alma"uğraşısı içerisindedir. Programcılar bu nedenle bir günde yüzlerce kararın altına imza atma becerisine sahip iyi birer karar vericidirler. Tam bu yoğun programlama sırasında birisinin programcının omzuna dokunduğu zaman bir "ara verme" operasyonu başlar. Bu ara verme operasyonu tam gaz giden bir arabada aniden frene basma gibidir. Derinleşen"kreatif" süreç derinliğini yitirir ve duyu organları"açılarak" omuza dokunan kişi ile iletişime geçilir.Bu geçiş çoğu zaman o kadar kolay olmamakta ve programcılar bu nedenle zor iletişim kurulan kişilerolarak görülmektedir. Bir soru sorulmaktadır. Eğer bu soru şu an üzerinde çalışılan konuyla ilgili ise mevcut kreatif süreç bu soruyu cevaplamakta kullanılır. Sorunun "bağlam" ile ilgili olması, sürecin durdurulmasını gerektirmez. Örneğin bir veritabanı tasarımında yandaki programcı bir tablodaki alanın ne işe yaradığını sorduğunda süreç durdurulmadan cevap verilebilir. Cevabın verilmesi için gerekli bütün malzeme, zaten o sırada beynin çalışma bölgesine getirilmiş hazır halde bulunmaktadır. Ama eğer bu soru bambaşka konularla ilgiliyse: "Bu iş ne zaman bitecek"ten tutun da , "dün maçı seyrettinmi?" ye kadar değişik açılardan gelen bir soru olabilir. Bu durumda ancak bu kreatif süreç durdurularak bu soruya cevap verilebilmektedir. Yada çoğu programcı bu soruyu "duyacak" ama"algılamayacaktır". O an durumu kurtaracak bir cevap vereceklerdir: "yarına biter" vs gibi. Yapılan basittir: kreatif süreç bölünmeden çalışmaya devam etmek istenmektedir. Bu sırada soruyu soran kişi doğal olarak programcıların zor iletişim kurulan kişiler olduğunu düşünecektir. Oysa programcının beyni hız kesmemeye çalışmaktan başka bir şey yapmamaktadır. Programcılar çoğu zaman konuşmayı pek sevmeyen ve zor iletişim kuran kişiler olarak bilinmektedir. Bu yanlış inancın temelinde, programcıların konsantre olma yetenekleri ve bölünmelere karşı geliştirdikleri iletişim "önlemleri" yatmaktadır. Oysa yazılım geliştirme ekipleri oldukça konuşkan olabilirler. Fark konuşulan konularda yatmaktadır... "Windows mu iyidir,Linux mu?" tartışmalarını dinleseniz programcıların az iletişim kurdukları konusundaki fikirleriniz tam tersi yönde değişecektir. Eğer bölündüğü sırada programcı soruyu tam olarak algılayıp doğru bir cevap vermeye çalışırsa, soru"bağlam" dışı ise kreatif sürecin durması gerekmektedir. Duran bu akışın yeniden eski kaldığı noktaya geri dönebilmesi, kişiye çok bağlı olmakla beraber, on beş dakikaya kadar çıkabilmektedir. Konsantre olma yeteneği yüksek olan programcılar bölünen bu süreci daha hızlı bir sürede eski noktaya getirebilmektedir. Programcılık sırasında beynin bu çalışma stilinin anlaşılması programlama ortamlarının ne kadar özenle seçilmesi gerektiği konusunda önemli ipuçları sağlamaktadır. Programcıların bu bölünmelerden korunması gereklidir. Daha da önemlisi programcıların kendilerini bu bölünmelerden korumaları gerekmektedir. Csikszentmihalyi ve ekibin yaptığı çalışmalar bu derin çalışma sürecinin ne kadar kırılgan olduğunu ve izolasyona ihtiyaç duyduğunu açığa çıkarmaktadır. Kanımca bir çok yazılım hatası (bug) bu bölünmeler sırasında ortaya çıkmaktadır. Televizyonda bir motoryağı reklamını izlediğimi hatırlıyorum. Reklamda"motor ısınıncaya kadar olan sürede aşınır yıpranır oysa bu motor yağı mıknatıs özelliklerine sahiptir ve motor çeperine yapışık kalarak ısınma sırasında bile motorun yıpranmasını önler" diyordu. Bu reklamda anlatılan olayı programcılıkta çok gördüğümüzü düşünüyorum. Yeteri kadar ısınmadan, soğuk bir"beyinle" yapılmaya başlanılan programcılık sonucunda oldukça "hatalı (bogus)" kodlar üretildiğini düşünüyorum. Meslek hayatımda karşılaştığım binlerce yazılım hatasını masaya yatırdığımda bu tür hatalarla karşılaştığımı görüyorum. Hataların bu kreatif sürecin hangi aşamasında yazılmış olabileceğini tahmin etmeye çalışıyorum. Bir programcı bölünme ile karşılaştığı zaman -üstelik bu bölünme bir SMS mesajı yazmak gibi zor ve zahmetli olup, beyni oldukça uğraştıran cinsten ise- programlama sürecinin beyinde eski aktivite düzeyine yükselmesi çoğu zaman yaklaşık 15 dakika sürecektir. Bu süreç sırasında hatasız bir kod üretimi için programcının kritik bir kod yazmaması gereklidir. Konsantrasyonun tam sağlanamayacağı bu ısınma dönemi, unutulan kontroller, atlanan olasılıklar ve hiç kodlanmayan program akış dallarına neden olacaktır. Çağımızda bu bölünmelerin başlıca sebepleri ceptelefonları, gelen SMS mesajları ve Instant Messaging programlarıdır. Bölünmemek için iletişimsizliğe ihtiyacımız varken çağımız bir iletişim çağı olmuştur. Watts Humprey, Software Engineering Institute tabanlıPersonal Software Process'in (Kişisel Yazılım Süreci -PSP) geliştiricilerinden birisidir. Kendisi uzun yıllar IBM'de çalışmış, OS390 projesinde yer almış ve yazılım geliştirmenin önemli duayenlerinden birisi olmuştur. PSP bir programcının iyi program yazması konusunda kendini nasıl geliştireceğinin ana hatlarını çizer. Humprey'in PSP'yi anlattığı "Introduction toPSP" kitabını aldığımda şaşırdığım bir konu olmuştu. Kitabın ilk bölümlerinin zaman yönetimi ve bu bölünmelere karşı mücadele olduğunu görüp şaşırmıştım. Humprey, programcıları bu bölünmelerle mücadele konusunda bilinçlendirmeye çalışıyordu. Yazılım geliştirme sürecinin tam verimiyle çalışması için bu sürecin korunmaya ihtiyacı olduğu çok açık. Bir programcının etrafında oturanlar, yöneticileri, ona SMS gönderenler bu sürecin geç cevap alacaklarının farkında olmalıdır. Böyle bir zihinsel durumdaki yazılım geliştirmeciyle olan iletişim senkron (eşzamanlı) değil asenkron (farklı zamanlarda) olmalıdır. Şu sıralar programcılıkta popüler olan yeni bir akım var. Entegre edilen sistemlerin birbirleriyle senkron bağlantılar yerine "loosely coupled" (gevşek eşleştirme) dediğimiz asenkron yöntemlerle bağlanması. Sanırım "akış" anını yakalamış bir programcı ileiletişimin de en sağlıklısı "loosely coupled" türden olacaktır.

Design Principles

• Identify the aspects of your application that vary and seperate them from what stays the same.
• Take what varies and "encapsulate" it so it won't affect rest of your code.
• Program to an interface, not an implementation. (Program to an interface really means program to a supertype.)
• "Has-a" can be better than "is-a"
• Strive for loosely coupled designs between objects that interact.
• classes should be open for extension, but closed for modification.

Kaf Dağına Yolculuk

Can Dündar'dan...

"Felsefe Taşı"nın peşindeki Harry Potter'a benzeyen 16 yaşındaki Umut'un Avustralya yerlileriyle tanışmak ve onlarla özgürlüğü yaşamak üzere evinden kaçtığını okuyunca, "İnşallah gidip hayal kırıklığına uğrama" demiştim.
Bazılarına cennet görünen yer, başkalarının cehennemi olabiliyor.
Tanışsak, Umut'a Avustralya'ya gittiğimde gördüğüm Aborjinlerden dinlediğim yürek yakan öyküleri anlatmak isterdim.
"Beyaz Adam'ın yerlilerin çocuklarını nasıl evlerinden kaçırıp manastırlarda dilinden, dininden, kültüründen kopararak hizmetçi olarak yetiştirdiğini...
... yüzbinlerce öksüz Aborjin'in bugün hala gerçek ane babalarını tanımadığını, tanısa da onlarla kendi dilinde konuşamadığını, bu yüzden de yerli dilin neredeyse tamamen yok olduğunu...
İki yüz yıllık bu asimilasyondan arta kalanlara bugün "kayıp kuşak" denildiğini...
Umut'un cennet umudunu kırmadan izaha çalışırdım. Sonra, başka bir öykü anlatmak isterdim ona...
İran mitolojisinin ünlü "Simurg efsanesi"ni...

*******************************************************************************

Simurg, bir masal kuşudur. Uzun boynunda beyaz bir halka bulunan, safran tüylü, güzel sesli, insana benzer kocaman bir kuş...
Kuşların sultanıdır.
Kaf Dağı'nın ardında yaşar.
Efsaneye göre, kuşlar, sultanlarını bulmak üzere toplanıp yola çıkarlar bir gün...
Yol uzun, yolculuk zorludur.
"Aşk Denizi'nden geçerler önce....
"Ayrılık Vadisi'nden uçarlar...
"Hırs Ovası'nı aşıp "kıskançlık Gölü'ne saparlar...
Kuşların kimi Aşk Denizi'ne dalar, kimi Ayrılık Vadisi'nde kopar sürüden...
Kimi hırslanıp düşer oovaya, kimi kıskanıp batar göle...
Yolculuk bittiğinde, Kaf Dağı'nın ardına sadece 30 kuş varabilmiştir.
Sultanları Simurg'u bulamazlar orada...
Sonunda sırrı sözcükler çözer:
Farsça "si" "30" demektir.
...murg" ise "kuş".
"30 kuş anlar ki aradıkları sultan kendileridir.
Ve gerçek yolculuk kendine yapılan seyahattir.
******************************************************************************
Çoğu mitolojik destan gibi, "Simyacı" da bu "kendinin efendisi olma" bilincini anlatır aslında...
Mısır piramitlerinin eteklerinde hazine arayan Endülüslü çobana Simyacı'nın dediği gibi,
"Yolculuk bir öğrenme yöntemidir. Bilmemiz gerekenleri bize o öğretir."
Saklı hazineyi, vurulduğu sevgiliyi, kaybettiği ülkeyi arayan gezgin, büyük sunavlardan geçüp yaman engeller aşarak kendi benliğine ulaşır, şuuruna kavuşur bu destanların Kaf dağlarında...
Ve sonunda "kendi hazinesi"ni bulur...
Anlar ki, keşfedilecek ülke insanın kendisidir.

Bir fincan kahve içer misiniz?

Bir fincan kahve icer misiniz?...
Is yasaminda önemli yerlere gelmis bir grup eski mezun arkadas grubu üniversitedeki hocalarindan birini ziyarete gitmis.Cesitli konular konusulduktan sonra sohbet, isin yarattigi strese ve hayatin zorluklarina gelmis.
Yasli üniversite hocasi ziyaretcilerine kahve ikram etmek üzere mutfaga gitmis ve degisik boy, renk ve kalitede bir cok fincanin bulundugu bir tepsiyle geri dönmüs.Kimi porselen, kimi seramik, kimi cam, kimi plastik olan fincanlari ve kahve termosunu masaya koyup kahvelerini oradan almalarini söylemis.
Tüm eski ögrenciler kahvelerini alip koltuklarina döndügünde hocalari onlara sunu söylemis:
"Farkina vardiniz mi bilmem, zarif görünümlü, güzel, pahali fincanlarin hepsi alindi, masada yalnizca ucuz ve basit görünümlü fincanlar kaldi.Elbette ki kendiniz için en güzelini istemek ve onu almak çok normal ama iste bu demin bahsettiginiz problemlerinizin ve stresin nedeni.Hepinizin istedigi fincan degil, kahve iken, bilinçli olarak herbiriniz birbirinizin aldigi fincanlari gözleyerek daha iyi olan fincanlari almaya ugrastiniz. Yasam kahveyse, is, para ve mevki fincandir.Bunlar yalnizca Yasam'i tutmaya yarayan araçlardir, ama Yasam'inkalitesi bunlara göre degismez. Bazen yalnizca fincana odaklanarak, içindeki kahvenin zevkini çikarmayi unutabiliyoruz."

JavaBeans versus Enterprise JavaBeans

Yeah, my new distrubuted objects course project is about EJB. I have already started to study it. I will talk about it later. But for now I want to mention difference between JavaBeans and Enterprise JavaBeans. There are two kinds of javabeans in java and if you are new in this subject you can easily get confused.
Here is a short definition from Mastering EJB book(3th edition pg:16) :

"You may have heard of another standard called JavaBeans. JavaBeans are
completely different from Enterprise JavaBeans.
In a nutshell, JavaBeans are Java classes that have get/set methods on them.
They are reusable Java components with properties, events, and methods
(similar to Microsoft ActiveX controls) that can be easily wired together to
create (often visual) Java applications.
The JavaBeans framework is lightweight compared to Enterprise JavaBeans.
You can use JavaBeans to assemble larger components or to build entire
applications. JavaBeans, however, are development components and are not
deployable components. You typically do not deploy a JavaBean; rather,
JavaBeans help you construct larger software that is deployable. And because
they cannot be deployed, JavaBeans do not need to live in a runtime
environment and hence, in a container. Since JavaBeans are just Java classes,
they do not need an application server to instantiate them, to destroy them,
and to provide other services to them. An EJB application can use JavaBeans,
especially when marshalling data from EJB layer to another, say to components
belonging to a presentation tier or to a non-J2EE application written in Java."

train once, code anywhere; write once, run anywhere...

ACE-TAO open source hell

Last month I had to study on TAO which is a open source version of CORBA for C++.
I choosed it since it is free and advised by my instructor. (I am a master student :) ).
For the first week I only tried to install and build it on my notebook. It was like a hell. Whenever I want to build it I took hundereds errors. On the fourth day I did it. It took about 6 or 7 hours to build!.
It was not all. After I build it, I started my project but I couldn't do anything because there is no API! or a user guide. How can I learn more than ten thousands classes and all methods of these classes' functionality without an API.
After I fought with TAO for two weeks, I gave up. I installed MiddCor which is a third party ORB for .NET environment. I installed it in just a few minutes!. I used it for server side. For client side java orb which comes with JDK seems more suitable to me. I gave my project by using these ORBs.
What I learned from this is that, open source is not always best choice. Documentation is at least as important as product itself. Otherwise this product becomes a limited thing that only a few people can use.
Days with more open and more documented :)

me