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.