Son zamanda RTFM kültürüne aşina olmayan bilgisayar mühendisi arkadaşlardan aldığım çok sayıda sorudan bazıları:
yaa ben stajda bi .net projesi yapıyorum da veritabanına bağlanamadım nası oluyo?
ya bizim arkadaş bişey yazmış da çalışmamış sana yollasam olurmu bi baksana.
[buraya msn’de 50 satır kod yapıştırılır] yaa üstteki kodun nesi yanlış? Çok normal sorular. Hiç yadırganacak bir tarafı yok.
Öncelikle sorunun saçma olduğu bu durumlarda genel olarak Doğru Düzgün Soru Sormanın Yolları yazısını önermek gerekiyor. Bence derdini anlatamayan bir mühendis (herhangi bir disiplinde) olamaz, olmamalı. Meslektaşlarınızla sağlıklı iletişim kuramıyorsanız işi gücü bırakıp iletişim yeteneklerinizi geliştirin.
Varsayalım ki sorunuzu eksiksiz ve cevap verecek kişinin en az düşünmesini gerektirecek hale getirdiniz. Derdinizi açıkça anlattınız, adım adım nasıl bu soruna vardığınızı, çözmek için hangi yolları denediğinizi ve ne sonuçlar aldığınızı sorunuza eklediniz. Çok güzel.
Bu yazı Bilkent Üniversitesi IEEE Öğrenci Topluluğu Teknoloji 101 dergisinin 7.sayısında yayımlanmıştır. İleride kaybolma ihtimaline karşı kendi bloguma da aktarıyorum. Ama siz yine gidip orijinalinden okuyun lütfen. :) Windows mu Linux mu?
Türkiye’deki bilgisayarların %99’undan fazlasında Windows işletim sistemi çalışıyor. [1] Fakat yazılım dünyasına yakın olan insanlar ve farklı yazılımları denemeyi seven kullanıcılar bilirler ki Windows’a alternatif olarak geliştirilen Linux tabanlı ücretsiz işletim sistemleri de var. (ör. Pardus, Ubuntu…) [2]
Peki, Windows mu daha iyi yoksa Linux mu? Bu soru yıllardır hem yazılımcılar hem de son kullanıcılar arasında büyük tartışmalara yol açmış, çoğu zaman da bu tartışmalar bir tarafın kullanıcılarının yaptığı fanatizm yüzünden bir yere varamamıştır. Hâlihazırda, zaten bu soru yalnız başına hiçbir zaman bir seçeneği galip çıkarmayacaktır. Kullanıcıların amaçlarına ve bilgi düzeylerine göre bu sorunun birden fazla yanıtı var. Şimdi yüzeysel ve en bilinen argümanlarla bu iki işletim sistemini karşılaştırmaya çalışalım.
Published under Creative Commons Attribution-NonCommercial license.
By “due date”, we mean the deadline to hand in a homework or other kind of deliverable assignment to the teacher.
Teachers should explicitly state a due date for each assigment with the announcement of the assigment.
Teachers should not postpone due dates after announcing a due date unless an extreme event happens (e.g. disaster, holiday announcement at last minute)
Bir ay önce düzenli olarak bloga yazı girmeye başlamıştım. Röportajlar, çeviriler falan havada uçuşurken bir anda kesiliverdim. :) Elbette ki okul hayatı zaman zaman durağan olup zaman zaman yoğunlaşıyor. Şu aralar aslında durağan zamanlara döndüm ama fırtına öncesi sessizliğin ta kendisi. Bu yüzden blogda yazı yazamıyorum, ölmedim yani merak etmeyin. :P
Açık standartlardan bahsettiğimiz şu günlerde web tarafında gelişmekte olan yeni bir spesifikasyon var: HTML 5. Kabaca açıklanacak olursa, yıllardır kullandığımız HTML’e, Flash, Silverlight gibi ek sistemlerle getirilen görsel zenginliği ve işlevselliği bu ekler olmadan sunabilmek için ortak bir standart olacak. Son zamanlarda Apple ile Adobe arasındaki iPhone’da Flash kavgası, Silverlight’ın sadece Windows’ta çalışması, dahası bu plug-in’lerin bilgisayarı yavaşlattığı bilinen bir gerçek.
8 ways to reduce bugs while coding yazısında yazılım geliştiriciliği yapılırken göz önünde bulundurulması gereken güzel noktalara değiniliyor. Bu nedenle Türkçe’ye çevirmemin faydalı olacağını düşündüm. Kendi eklemelerim de var. Umarım faydalı olur.
[caption id=“attachment_1719” align=“alignright” width=“300” caption=“Acrosternum hilare (a.k.a osuruk böceği)”][/caption]
**Testler yazın: **Hazırladığınız modüller için birim testleri (unit test) ve bütünlük testleri (integration test) yazın. Test-Code-Test prensibini uygulayın, kodlarınızı yazdıkça test edin. Metodların mümkün olabilecek bütün girdilerine göre davranışlarını nasıl idare ettiğini gözlemleyebileceğiniz test durumlarını (test case) hazırlayın. Düzenli olarak çalıştırabileceğiniz otomatize edilmiş test durumlarınızın olması hataları erken fark edebilmenizi sağlar.
Araçlar kullanın: Statik kod analiz araçları işinize yarayabilir. Örneğin Findbugs, Java kodlarınız üzerinde incelemeler yaparak olası hataları (bug) bulmanızı sağlar, Ruby için GetExceptional, Python için pylint, PyChecker kullanabilirsiniz. Web uygulamalarınızdaki olayları ve elementleri de Selenium ile birden fazla tarayıcıda otomatik olarak test edebilirsiniz.
Uzun süredir değinmek istediğim bir konu, belki de Türkiye’den çıkmış tüm zamanların en harika web girişimlerinden biri put.io. Tanıtımı ve ne iş yaptığıyla ilgili pek çok yazı başka bloglarda mevcut. Fakat put.io sıradan bir web girişiminden öte, bir çok mühendislik problemine güzel çözümler getirmesiyle dikkat çekiyor. Bugün put.io’nun kurucularından Cem Başpınar (aftermath) ile put.io’daki teknik konular üzerine bir söyleşi yaptık. Umarım put.io ile ilgili efsanelere ve aklınızdaki sorulara yanıt olur. :)
**
put.io’nun büyük kısmında PHP üzerinde çalışan bir web çatısı olan Symfony‘i kullanıyoruz. Sistemin altyapıdaki işleyişini sağlayan job‘ların çoğu yine PHP, bazıları ise Python‘da kodlanmış durumda. İlk başlarda PHP’yi seçme sebebimiz bu dilde geçmişte edindiğimiz iyi tecrübeler, know-how ve ekibimizin bilgisi ön plandaydı. İlerleyen zamanlarda PHP’nin memory management’ı iyi yapamadığını gözlemledik. Zaman zaman job’larda gereksiz şişmeler oluyordu. Python’da ise bu sorun olmuyor ve performansı çok daha iyi.
Bilkent IEEE Öğrenci Kolu TEKNOLOJİ 101 e-dergisinin Eylül 2010 sayısında çıkan “Google neden en iyisi” başlıklı kısa yazım üzerine birkaç şey eklemek istedim. :) Epeydir süregelen Google hayranlığım doğrusu yakın zamanlarda sekteye uğradı. Elbette Google her zaman en iyisi değil. Fakat yaptığı işlerde en iyi araştırmaları yapıp ürünleri en doğru şekilde ortaya çıkaran şirket. En basitinden web’in ilk zamanlarından beri arama motorları var. Fakat insanlara en ilgili sonuçları en kullanışlı biçimde sunmayı Google’ın keşfettiği bir gerçek.Yazıda da anlattığım neredeyse bütün Google ürünlerinin arkasında bilgisayar bilimleri (computer science) dalları var.
İlginçtir ki biz mühendisler (Amerikalıların deyimiyle) roket bilimi yapmaya bayılıyoruz. Yaptığımız şeyleri nasıl daha karmaşıklaştırıp artistik biçimlerde yapabiliriz demenin yollarını arıyoruz. Doğrusu hedef kitleniz, yani kullanıcınız yaptığınız bu mühendisliği ne biliyorlar ne umursuyorlar. Yani “they don’t give a shit”. Bu yüzden bir web projesinde önemli olan ürünü sunuş biçimini doğru yapmak.
Berker‘in paylaşımından denk geldiğim ve görüşlerime tercüman olan Shalin Shekar Mangar‘ın bu yazısını Türkçe’ye çevirme ihtiyacı hissetim. Kendi görüşlerimi eklemiyorum, bu yüzden tartışmaya oldukça açık. İleride çok sayıda insanı yönlendirebilecek bir yazı bulunması umuduyla çevirdim. Umarım faydalı olur. Keyifli okumalar. Not: Aşağıdaki yazı ve sunum Allahabad-Hindistan Bilgi Teknolojileri Enstitüsü’ndeki (IIIT) öğrencileri açık kaynaklı projelere, özellikle Apache Lucene, Solr ve Hadoop üzerine katkıda bulunmak konusunda teşvik etmek için hazırlanmıştır. Birinci konuşma bu iken ikincisi “Apache Software Foundation ile Tanışın” konuludur ve 2., 3. ve 4. sınıf öğrencilerine Lucene, Solr, Hadoop projeleri hakkında kısmen teknik bilgi vermek için hazırlanımştır.
Herkes havalı projelerde çalışmak ister. Lakin gerçek hayatta büyük ihtimalle maaşı iyi olsa bile bir işte veya pozisyonda takılıp kalırsınız ve çok düşük ihtimalle bu iş üzerine çalışmak istediğiniz konularla ilgilidir. Derslerde algoritmalar, dağıtık sistemler, doğal dil işleme, bilgi temini (information retrieval), biyoinformatik ve birçok bilgisayar bilimi ve uygulamaları hakkında konular öğrenirsiniz; fakat gerçek hayatta yazılım şirketlerinin çoğunda yapılan işlerin sadece küçük bir miktarının derslerinizde öğretilenlerle alakası vardır.
reCAPTCHA, bilmeyenler için, Facebook-Twitter gibi bir çok büyük sitede kullanılan ve iki kelimeden oluşan resimli “güvenlik kodu” uygulaması. Aslında yaptığı şey, Google Books tarafından taranıp internete aktarılan 10 milyondan fazla [1] kitabın OCR okuyucular tarafından okunamayan kısımlarının kullanıcılara okutulması. Son zamanlarda Google tarafından satın alınan [2] reCAPTCHA ile aslında kullanıcılar girdikleri kelimeler ile OCR okuyucularının okuyamadığı kelimeleri insanı hesaplama kabiliyetlerini kullanarak okuyorlar, hem de bir güvenlik doğrulaması sağlanmış oluyor. Bir süredir üzerinde kafa yorduğum konulardan biri de human based computation. Bir şekilde insanların beyin gücünü kendi uygulamanızın faydası için kullanıyorsunuz. CAPTCHA’nın (basit güvenlik kodu sistemi) yaratıcısı genç profesör Luis von Ahn tarafından Carnegie Mellon’da geliştirilen reCAPTCHA aslında başlarda sadece OCR sistemlerin okuyamadığı yazıları kullanıcılara okutmak için tasarlanıyor, ama daha sonralarda Google Books’un yüzlerce kütüphanede devam eden kitap tarama operasyonundan beslenmeye başlıyor.