belgeler.org sitesi güncellendi. Man sayfaları çevirilerine http://www.belgeler.org/man/manpages.html adresinden erişebilirsiniz. Sisteminize kurmak için gerekli paketleri http://sourceforge.net/project/showfiles.php?group_id=61526
adresinden elde edebilirsiniz. Dağıtımlar içinden çıkacak Türkçe kılavuz sayfaları dileğiyle.
Görüşler
Görüş belirtmek için giriş yapın...İlgili Yazılar
Linux´da Bellek Yönetimi Başlangıcı
Bora Şahin arkadaşımızın Linux'da Bellek Yönetimi Başlangıcı başlıklı detaylı ve özgün makalesi "kernel hacking" ve genel olarak sistem programlama ile ilgilenen okuyucularımızın hizmetine sunulmuştur.
Qooxdoo JavaScript / AJAX Framework İle Merhaba Dünya'dan Biraz Öteye
Aşağıdaki eğitsel burada yayınlanan (İngilizce) aslından çeviridir. Gerek benim yeteneksizliğim gerekse Türkçe'nin bilişim terimleri konusunda zayıf olması sebebiyle kötü bir çeviri olmuştur. Çeviri için özür diliyor ve mümkünse aslını okumanızı rica ediyorum.
Qooxdoo özellikle masaüstü benzeri GKA'lar yaratmakta kuvvetli bir AJAX çatısı. Tkinter veya GTK gibi, ama daha çok swing'e benziyor. İyi hazırlanmış belgeler ve temiz bir API ile geliyor. Yapılandırma ve ilklendirme için küçük bir Python programı var. Çok geniş bir kütüphaneye sahip olduğu için geliştirme sürecinde kısmen derlenmiş kaynak üzerinde çalışıp, bitirdiğinizde yine bu programı kullanıp tek (aslında iki, bir de yükleyici oluşturuyor), az yer kaplayan bir dosya oluşturabilirsiniz.
HTML, JavaScript ve PHP ile E-Posta Takibi
Düşünün ki eski bir dostunuza ya da eski sevgilinize e-posta atıyorsunuz ama onun bu iletiyi okuyup okumadığından emin olamıyorsunuz! :)
Ne yapacaksınız? Oturup merak içinde bekleyecek misiniz? Tabii ki hayır! ;)
Peki ne yapmalı?
Önce derdimize çare olacak bir sistem taslağı çizmeli tabii ki...
Değerli FM üyelerinden Gökhan "Crematorium" Olgun´un "gönderdiğiniz e-postanın okunup okunmadığını kolayca takip etme" amaçlı makalesinin devamını bu adreste okuyabilirsiniz.
Ne yapacaksınız? Oturup merak içinde bekleyecek misiniz? Tabii ki hayır! ;)
Peki ne yapmalı?
Önce derdimize çare olacak bir sistem taslağı çizmeli tabii ki...
Değerli FM üyelerinden Gökhan "Crematorium" Olgun´un "gönderdiğiniz e-postanın okunup okunmadığını kolayca takip etme" amaçlı makalesinin devamını bu adreste okuyabilirsiniz.
Matrix ve Felsefe
Sizin de kafanız Keanu Revees gibi Matrix'ten sonra karıştıysa bu kitap kesinlikle sizin için yazılmış. Eğer film kafanızı karıştırmadıysa, hemen bir doktora görünün. Matrix'i henüz seyretmediyseniz, o zaman bu kitabı mutlaka okumalısınız. Böylece bu filmin insanlar için neden o kadar önemli olduğunu bulursunuz.
Dil Üstadları ile Araç Ustaları: IDE Ayrımı
Geliştirici dünyası iki kampa ayrılmıştır. Bir kampta dil üstadları vardır, bu yazılımcılar yüksek seviyeli programlamadan -- birinci-sınıf fonksiyonlar, aşamalı programlama, AOP, MOP, kendi kendini sorgulama -- bahsederler. Araç ustaları ise tümleşik geliştirme ve hata ayıklama araçlarında ustadırlar, kod tamamlama, "refactoring", vs. Dil üstadları Emacs ya da VIM kullanır, bu tür editörler yeni dilleri denemek için daha uygundur. Araç ustaları ise Visual Studio, Eclipse, IntelliJ gibi IDE'leri kullanırlar.
Laszlo ve Groovy gibi yeni diller ya da AOP (Aspect Oriented Programming) gibi dil uzantıları genellikle öncelikli olarak metin-editörü tabanlı yazılım geliştirme ortamlarında ortaya çıkarlar ve ancak ondan bir süre sonra IDE dünyası bu tür desteklere kavuşur. Eğer dil ya da uzantı gerçekten başarılı ise araçlar da bunu desteklemeye başlar. Bu ayrımın tek sebebi araç geliştirmenin dil geliştirmekten zor olması değildir. Asıl mesele bir dile hakim olmak ile bir araç setine hakim olmanın çok farklı iki mantalite olmasıdır, belli bir ölçüye dek bunlar birbirlerini dışlayan alternatiflerdir. Acaba neden? İşte sebepleri...
Oliver Steele'nin The IDE Divide başlıklı makalesini tüm yazılım geliştiricilerin okumasında fayda var. (Not: Şöyle sağlam bir FM üyesi çıksa da bahsi geçen makaleyi Türk diline kazandırsa... hani yani küçük bir olasılık olsa da, belki diyorum, belki biri üstlenir, FM'ye bir katkıda bulunur...)
Laszlo ve Groovy gibi yeni diller ya da AOP (Aspect Oriented Programming) gibi dil uzantıları genellikle öncelikli olarak metin-editörü tabanlı yazılım geliştirme ortamlarında ortaya çıkarlar ve ancak ondan bir süre sonra IDE dünyası bu tür desteklere kavuşur. Eğer dil ya da uzantı gerçekten başarılı ise araçlar da bunu desteklemeye başlar. Bu ayrımın tek sebebi araç geliştirmenin dil geliştirmekten zor olması değildir. Asıl mesele bir dile hakim olmak ile bir araç setine hakim olmanın çok farklı iki mantalite olmasıdır, belli bir ölçüye dek bunlar birbirlerini dışlayan alternatiflerdir. Acaba neden? İşte sebepleri...
Oliver Steele'nin The IDE Divide başlıklı makalesini tüm yazılım geliştiricilerin okumasında fayda var. (Not: Şöyle sağlam bir FM üyesi çıksa da bahsi geçen makaleyi Türk diline kazandırsa... hani yani küçük bir olasılık olsa da, belki diyorum, belki biri üstlenir, FM'ye bir katkıda bulunur...)