Wikipedia in schools

Wikipedia in schools:

"It can fairly be argued that Wikipedia is one of if not the greatest collaborative successes on the Internet, and it so happens that like schools, it is in the business of spreading knowledge."

"Students in high school and university, perhaps even middle school, already spend innumerable hours researching and writing papers that will only be read by a few people before being forgotten. Teachers and professors in high school and university are a cadre of adults who have spent their lives learning, understanding, expanding, and teaching certain academic subjects. All of these people deal with spreading/learning knowledge on a full time basis. If just a small fraction of these people (34+ million high school and college students in US), both students and teachers, were systematically encouraged to become regular editors of Wikipedia (and sister projects), the results would be incredible."

"Schools should encourage Wikipedia volunteering just as much as they promote the more "traditional" types of such work, and frankly, editing can be a far more academic pursuit than pulling weeds at the local park."

On Starting a Long-Term Company

On Starting a Long-Term Company:

"...if you ever delegate without understanding, things will get messed up."

"...if you're the one who cares, you should be the one pushing things forward. You can't delegate the core motivation."

Biraz da edebiyat

Geçenlerde sevgili eşimin defterlerinde gördüğüm bir yazı (şiir?) çok hoşuma gitti:

Yoldan geçiyordu, durdu...
bir bahçe vardı.
donuk adımlarla, adım adım bahçenin duvarına yöneldi
donuk gözlerle çiçeklere baktı, baktı..
çiçekler sıcaktı.
donmuş bir sesle bahçıvana sustu:
-bu çiçekler kesilecek mi, bu çiçekler gidecek mi?
bahçıvan dizlerine bahçeyi çöktü,
yüzüne çiçekleri döndü.
bir ışık yanmıyordu, yandı, söndü...
elleri gözlerine baktı, gözleri ellerine aktı.
gözleri ellerini gördü, elleri kördü
sönen ışık yandı, yanan ışık söndü...
dün yağmur yağacaktı,
gün döndü yarın yağdı, bugün dindi...
ağlayacaktı, kim anlayacaktı...

Özdemir Asaf / Yalnızlık Paylaşılmaz

Bir de bugün eski kasetleri atmak üzere karıştırırken sonunda Salkım Söğüt'ün Grup Baran bestesini buldum ve ara kablo ile mp3 olarak kaydettim. Şiirden en sevdiğim bölümler:

Akıyordu su
gösterip aynasında söğüt ağaçlarını.
Yıkıyordu salkımsöğütler suda saçlarını.
Yanan yalın kılıçları çarparak söğütlere
koşuyordu kızıl atlılar güneşin battığı yere.
...
Ah ne yazık!
Ne yazık ki ona
dörtnala giden atların köpüklü boynuna bir daha yatmayacak,
beyaz orduların ardında kılıç oynatmayacak.

Nal sesleri sönüyor perde perde,
atlılar kayboluyor güneşin battığı yerde...
...
Ağlama salkımsöğüt, ağlama.
Kara suyun aynasında el bağlama.
El bağlama, ağlama.

Nazım Hikmet / Salkım Söğüt

mp3:

* Leona Lewis - Bleeding Love
* Gnarls Barkley - Crazy

Google'ın bir aya gitmediği kalmıştı!

Google 2012 yılına kadar aya bir robot gönderebilen ilk iki devlet-dışı ekibe 30 milyon dolar ödül vereceğini açıkladı. Bir kez daha bizlere paranın insanların hayal gücünü geliştirmek için nasıl kullanılabileceğini gösterdiler. Abi büyüksünüz: Google Lunar X Prize, Join the revolution: Moon 2.0



Ve bir alkış da Peter Diamandis'e, Extraordinary feats of an X-Man

Bahtsız bedevi

İngilizce Yazılım Projesi

İnternette gezinirken sürekli bilmediğim ingilizce kelimelerle kaşılaşıyorum. Kelime dağarcığımı geliştirmek için idealde yapmam gereken kelimeleri ingilizce açıklamaları ve içinde geçtikleri cümlelerle birlikte not etmek. Ama şimdi kelimenin anlamını internetten bul, kelimeleri not ettiğin dosyayı aç, içine kelimeyi, anlamını ve örnek cümleyi kopyala, dosyayı kapat... Uzun iş. Onun yerine kelimeyi işaretleyip tek bir sağ klikle işlemi halletmek ister tembel gönlüm. Bu işi otomatik olarak halledecek bir program yazmayı düşünüyorum. Programı tamamladığımda aşağıdakine benzer bir işlevsellik sunmalı.


Temel özellikler:
* Sağ klik menüsüne kendi programımı eklemeliyim. Mümkünse menünün ilk maddesi olsun.
* Program web sayfasında işaretlenen kısmı text dosyasına yazmalı (bir çeşit "selected" özelliği olmalı).

İleri düzey özellikler:
* Eğer tek kelime seçmişsem program webster vb. sözlük sayfalarını sorgulayıp kelimenin ingilizce anlamını da dosyada yanına yazmalı.
** Program kullanarak sayfa yüklemesini öğren (IE API?)
** http://www.webster.com/dictionary/consternation adresindeki sayfayı yükle
** Sayfa kaynak kodunda '<'div class="defs"'>'bölümündeki tanımı al.

* Text dosyası değil de html dosyasına yazmalı. Dosyada kelime, anlamı ve örnek cümle için üç sütundan oluşan bir tablo olmalı. Eğer tek kelime seçmişsem tablonun birinci sütununa kelime, ikinci sütununa ise internetten otomatik bulunmuş ingilizce anlamı yazılmalı. Bir kelimeden fazlasını işaretlemişsem örnek cümle kabul etmeli ve üçüncü sütuna koymalı.

* IPhone vb. taşınabilir bilgisayarlarda çalışabilmeli

* Program beni sınava çekmeli:
** Kelimeyi sormalı, şıkları veritabanındaki diğer kelime anlamlarından oluşturmalı.
** Kelimenin geçtiği cümleyi içindeki kelimeyi silerek vermeli, buraya hangi kelime gelir diye sormalı, şıkları veritabanındaki kelimelerden oluşturmalı.
** Kelimeyi vermeli, şıkları içlerindeki bilinmeyen kelime silinmiş cümlelerden oluşturmalı.
** Doğru cevaplandırdığım kelimelerin sorma sıklığı düşmeli (bkz Flashcard yöntemi)
** Program performans tarihçemi tutmalı (kaç doğru, kaç yanlış, yanlış cevaplandırılan kelimelerin listesi vb.)

Programı yazdıktan sonra kamuya açacağım. Eklenmesinde fayda gördüğünüz özellikleri comment kısmında belirtelim.

Kitaplık tasarımı

Uzun zamandır arzu ettiğimiz gibi şeffaf cam kapaklı güzel bir kitaplık arıyorduk. Sonunda hazır olarak bulamayacağımıza karar verip kendimiz tasarladık. Tasarımı Google Sketchup ile yapınca boyutların mantıklı olup olmadığını üç boyutlu şekil üzerinde görmek mümkün oldu. Tasarımımı 3D Warehouse'da kamuoyunun kullanımına sundum.


Mobilya siparişini ise Ankara Siteler'deki Aydınoğlu Mobilya'ya verdim. Biraz tuzlu ama güzel iş çıkarıyorlar. Benim selamımı söylerseniz ilgi görürsünüz ;)

Adresi şu:

Aydınoğlu Mobilya Dekorasyon Tic. Ltd. Şti.
Yetkili : Orhan Aydın
Telefon : (0312) 348 95 32
Adres : Karacakaya Caddesi No:65/A Siteler, Ankara

Bitmiş hali de şu:

Wikipedia Analiz Aracı

İlginç bir wikipedia analiz aracı: User Edit Counter

Bkz. benim İngilizce wikipedia istatistik sayfam

Bkz Türkçe vikipedi istatistik sayfam

Diğer araçlar için bkz. Toolserver Table of Contents

Aaron'dan wikipedia ile ilgili güzel bir yazı: Who Runs Wikipedia?

Unit Testing

I started making use of unit testing. Unit: smallest testable part of an application. At first, I was a little bit sceptical. "This tests are way too simple" I said to myself. But as the project grew in size, I realized the assurance my unit tests provided. They were the first line of defense against bugs. It allowed me to try new things with my code without being afraid of blowing things up.

My advice to the sceptical is: You write temporary little tests to check your code anyway. Instead of throwing them away, arrange them into unit tests. If nothing else, your unit tests will serve as a written reminder of what you have tested, and -more importantly- what you have not.

The Developer Testing Paradox by Alberto Savoia:

"When developers concentrate their efforts on unit tests, QA can focus on its real job – system and integration testing, load and stress testing, and independent verification – rather than having to find unit-level bugs that developers should have already caught and fixed."

"Left unchecked, a relatively small number of unit-level bugs can easily multiply and impair a software system so insidiously that bringing it back to a reasonable level of quality and usability may be impossible or, at best, horrendously painful and expensive. If you don’t pay attention to bugs early enough, you can easily end up with a system that is such a nightmare to maintain, evolve, and yes, even test, that the best option may be to throw it away and start over."

"...a single unit-level bug can infect the system and manifest itself in many other modules, forcing the QA organization to submit multiple bug reports – each of which takes valuable time to reproduce, file, verify, etc."

"If the tests are not executed frequently enough (ideally several times a day, matching the rhythm of code changes), much of their effectiveness will be lost."

"Test failures are a very good thing. They are evidence that the tests are thorough and are doing their job of detecting bugs and changes in the code behavior which, left unaddressed, could lead to further and more serious bugs."

"There is nothing like the feeling of confidence and protection that we get by having tens of thousands of test points spread across numerous tests that are run several times a day. System and integration tests are still necessary and useful, but they can’t match the fine granularity, resolution, and assurance of having specialized tests for each unit of code."

N. R. Narayana Murthy

"In December 2005, Narayana Murthy was voted as the 7th most admired CEO/Chairman in the world in a global study conducted by Burson-Marsteller with the Economist Intelligence Unit. The list included 14 others with distinguished names such as Bill Gates, Steve Jobs and Warren Buffett." -Wikipedia

Quotes:

* Performance leads to recognition. Recognition brings respect. Respect enhances power. Humility and grace in one's moments of power enhances dignity of an organisation.
* The real power of money is the power to give it away.
* In God we trust, everybody else bring data to the table.

Management is an Attitude

Eric Nehrlich, Management is an Attitude:

"A recent realization is that being a manager isn’t something that others can bestow upon me. The way to get others to treat me as a manager is not to wait for mystical authority to be granted to me, like the sword from the stone. It’s to start acting like a manager. This means taking responsibility for other people’s actions, which is a terrifying thing.

I have no problems being responsible for my own actions, because if I screw up, it’s because of factors under my direct control and I’m happy to accept the blame for that. Taking responsibility for others means I have to take responsibility for things that are not under my direct control.

If I can’t convince somebody to change, maybe I’m wrong. Maybe it’s my responsibility to continue reframing my ideas until I can convince them. Or to at least bring the issue out into the open so we can discuss it.

It means I am responsible for continuous and effective communication so that they can make appropriate decisions."

Eric Nehrlich

Bu aralar Fogbugz'ı deniyorum. Fogbugz teknik destek forumunda soruları cevaplandıran Eric Nehrlich de kim ola diye baktığımda enteresan bir bloğu olduğunu gördüm. Adamımız MIT fizik mezunu, Joel'in yanında çalışıyor, teknoloji yönetimi üzerine mastır yapıyor (strateji üstadı Nefis Bey'in dikkatine). Bloğu: Unrepentant Generalist

Okuduğu kitaplarla ilgili yorumları: Books

Prosedürler

Genel kanıya göre organizasyonlar büyüdükçe iş yapma biçimlerini yazılı hale getirmeye, yani prosedürlere/süreçlere ihtiyaç duyuyorlar. Bunun ne kadar doğru olduğunu şimdilik bir kenara bırakalım. Temel sav işlerin tekrarlanabilir/öngörülebilir bir kalite seviyesinde yapılabilmesi. Prosedürler özellikle hataları önleme görevi görüyorlar. Ezberci, "olsa iyi olur" yaklaşımlarla prosedürler hazırlandığında ise pratikle alakasız fantazilerle dolu hale geliyorlar. Prosedürleri hazırlarken sorulması gereken üç soru var:

* Çözmeye çalıştığımız problemin oluşma olasılığı yüksek mi?
* Sorun oluştuğunda hayati problemlere yol açacak mı?
* Yazılı kurallar olmadan sorunu aşmak zor mudur?

Eğer bu üç sorunun hepsine birden EVET demiyorsak yazılı kurala gerek yok demektir. Antoine de Saint-Exupery'nin tasarım için söylediği prosedürler için de aynen geçerlidir.

Yazılı kuralların esnekliği, yaratıcılığı, dolayısı ile de motivasyonu ve verimliliği olumsuz etkileme gibi çok ağır bedelleri olabileceği unutulmamalıdır. Atılan taş ürkütülen kurbağaya değmelidir.

Üç soruya evet dedikten sonra kuralları yazarken de her maddenin yanına mutlaka kuralın neden yazıldığını, neye dayandığını belirtmek gerekir (Geçmişte yaşanmış X olayı, ISO 9000 madde bilmemkaç gereksinimi vb.) Böylece kuralın neden var olduğunu herkes anlayabilir, izlenebilirlik sağlanmış olur.

İşyerindeki yazılı süreçlerin başarısı, süreçten ne kadar az bahsedildiği ile doğrudan ilgilidir. Eğer sürekli süreçlerden bahsedilmeye başlamışsa süreçler aksıyor demektir. Başarılı prosedürler görünmez olanlarıdır.

Başarıya giden en kısa yol ise prosedürlerden değil, insanlardan geçer. İşyerine çalışan olarak süper kahramanları alın ve gelişmeye, eleştiriye açık uygun ortamı sağlayın (misal vasat insanları Dar-ül Aceze'ye havale edin). Süper kahramanlar işleri düzgün yapmak için ne gerekiyorsa (hem teknik, hem de idari manada) zaten yapacaklardır.

Hitting the high notes:

"The real trouble with using a lot of mediocre programmers instead of a couple of good ones is that no matter how long they work, they never produce something as good as what the great programmers can produce."

Clay Shirky on Process: "...Clay Shirky’s observation that “Process is an embedded reaction to prior stupidity”. ...an organization slowly forms around avoiding the dumbest behaviors of its mediocre employees, resulting in layers of gunk that keep its best employees from doing interesting work, because they too have to sign The Form Designed to Keep You From Doing The Stupid Thing That One Guy Did Three Years Ago"

"Take a quick read through the (Joel recommended) book “Slack”. The author makes an interesting observation about process: the hard part is not covered by the process.

For example, to fix a bug:
a) create a branch
b) create a test
c) when the work lasts more than 4 hours, write a spec
d) fix the code
e) checkin and test

Obviously, the real work is in b & d and maybe c, but the process doesn’t help you do that. The process is helping with the easy things."

Debugging 101

From the Hacknot Book:

"It seems strange that I never learnt in any structured way how to debug a program. Everything I know about debugging has been acquired through experience, trial and error, and from watching others. Unless my experience is unique, it seems that debugging techniques should be a topic of vital interest to every developer."

List of techniques:

* Reproduce
* Progressively Narrow Scope
* Change Only One Thing At A Time
* Insert Trace Statements
* Search The Web For The Stack Trace
* Insert assertions
* Read The Documentation

* Polish documentation: If you debug/refactor an algorithm and its documentation is missing/insufficient, try documenting it. This will enable you to think more clearly. Example: If you try to debug the collision detection algorithm, start by documenting (comments, a word document with illustrations etc.)

* Recompile And Relink
* Probe Boundary Conditions And Special Cases
* Check Code That Has Changed Recently
* Don't Trust The Error Message
* Explain/discuss the bug to a colleague
* Don't Be Too Quick To Blame The Tools
* Understand Both The Problem And The Solution
* Take A Break
* Introduce Debugging Aids Early (logging, unit test etc.)
* Loose Coupling And Information Hiding
* Write A Regression Test To Prevent Reoccurrence
* For long debugging sessions (>1 week) keep a written history of the things you tried and the results you got so that you don't repeat yourself and loose time

* While in the process of debugging, write down what you are doing and plan to do (debug diary). This has a similar effect of talking about the problem with someone else; it helps to think more clearly and not get overwhelmed/depressed. Additionally, during debug sessions spanning more than one day, you will not forget what you did (and not waste time re-doing things).

* In code there should be special comments for lines that show the main flow. In that way it will be easier to follow the main flow amidst all the auxilliary data reading, comments, error handling, resetting etc. Example using --!!! MAIN FLOW comment to indicate important functions. [Code Complete, Steve McConnel, 1993, p.40]:

"...as much as 90 percent of a program's code is written for exceptional, error processing cases or housekeeping, implying that only 10 percent is written for nominal cases"

* When coding a complex model, first start coding the simplest configuration by making assumptions (const g, no drag, QE=0), do some tests, code them as unit tests or at least jot down assumptions and inputs/outputs. Then one by one remove the simplifying assumptions, update the design to accomadate new functionality, check if the old tests still pass and add new tests. That way you will not be overwhelmed by complexity and you will always have a running program.

Update 19.02.2018:

Perfection in design

“You know you've achieved perfection in design, not when you have nothing more to add, but when you have nothing more to take away.”

– Antoine de Saint-Exupery

The Road To Build Enlightenment

A recurring story in software development (especially large ones) is the difficulty of getting a new commer up and running. You hear phrases like "it works on my machine", "I had the same problem 6 months ago, but forgot how we solved it". Read If They Come, How Will They Build It for details of this nightmare. I heard the following more than I care remembering (and I will kill someone the next time!):

"Ed: It's taken me nearly two weeks of stuffing around to get a development environment setup for AccountView. That's a fair productivity hit. have you considered writing all the necessary steps down so that newcomers can just follow the instructions instead of having to piece it together for themselves.

Mike: documentation, I'd love to write a dev env setup guide, but I just don't have the time!"

"The idea of the existing project staff having a responsibility to define their own work procedures and methods with sufficient rigor that it is possible for new arrivals to get up to speed, just doesn't seem to occur to anyone."

Fortunately, the cure is well known. The Road To Build Enlightenment: "This article describes the properties of an effective build system, starting from the most basic requirements and working towards more advanced features. Follow the article step-by-step to drag your build system out of the darkness and attain build enlightenment!"

See also The F5 Key Is Not a Build Process

Set Your Priorities - Joel on Software

Set Your Priorities - Joel on Software: "So if you want to get things done, you positively have to understand at any given point in time what is the most important thing to get done right now and if you're not doing it, you're not making progress at the fastest possible rate."