Wednesday, January 30, 2013

Sunday, January 27, 2013

Yaratıcı Kalmanın 33 Yolu

Facebook'ta denk geldiğim güzel bir listeyi tercüme ettim. Uygulayın, eğlenin...


1. Liste yapın
2. Yanınızda hep bir not defteri taşıyın
3. Serbest yazımı deneyin
4. Bilgisayardan uzak durun
5. Diğer-Dünyalı olun
6. Kendinize eziyet etmeyi bırakın
7. Ara verin
8. Duşta şarkı söyleyin
9. Çay/Kahve için
10. Köklerinizi unutmayın
11. Yeni tür müzikler dinleyin
12. Açık olun
13. Çevrenizi yaratıcı insanlarla kuşatın
14. Geribesleme alın
15. İş birliği yapın
16. Vazgeçmeyin
17. Uygulayın, uygulayın, uygulayın
18. Kendinize hata yapma izni verin
19. Yeni yerlere gidin
20. Yabancı menşeili filmler izleyin
21. Şükredin
22. Bolca dinlenin
23. Risk alın
      24. Kuralları yıkın
25. Sizi mutlu eden şeyleri daha sık yapın
26. Zorlamayın
27. Sözlükten bir sayfa okuyun
28. Bir çerçeve oluşturun
29. Bir başkasının mükemmeli olmaya çalışmayı bırakın
30. Bir fikriniz mi var? Hemen yazın
31. Çalışma alanınızı temizleyin
32. Eğlenin
33. Bir şeyleri bitirin.



33 Ways to Stay Creative

I saw this picture on facebook, and posted in here.
Apply it and have fun.


Friday, January 25, 2013

If You Are Waiting For a Sign...

... to start your own business,
... to start a healthy life,
... to quit smoking,
... to say someone that you are in love,
... to enroll to a course,
... to change the way you live...



Tuesday, January 22, 2013

"Günde Bir Tane"nin Gücü

Aşağıdaki blog mesajında, Seth Godin'in bir blog mesajını birebir tercüme ettim; çok güzel fikirler yazmış Seth.

Günde Bir Tane'nin Gücü
Bir yılda en az 200 iş günü vardır. Eğer her bir gününüzü sadece bir tane basit pazarlama aktivitesine ayırırsanız, yıl sonunda bir dağ oluşturmuş olursunuz. Aşağıda, deneyebileceğiniz bir kaç öneri var (hepsini birden yapmaya çalışmayın, sizin için değişiklik yapacağına inandığınız tek bir şeyi yapın):
  • Bir müşterinize el yazınızla kişisel bir teşekkür notu gönderin
  • Ürün veya hizmetlerinizin bir müşteriniz tarafından nasıl kullanıldığı hakkında blog yazın
  • Sektörünüzle ilgili bir konuyu araştırın ve nasıl işlediğine dair kısa bir makale yayınlayın
  • Birbirlerine faydası dokunacağını düşündüğünüz iki meslektaşınızı tanıştırın
  • Bir iş veya nasıl-yapılır kitabının ilk üç bölümü okuyun
  • Müşterilerinize bir şeylerin nasıl yapıldığını anlatan bir video kaydedin
  • En az bir çalışanınıza yeni bir yetenek kazandırın
  • On dakikalık bir yürüyüşe çıkın ve dünyaya sunduklarınızı geliştirecek en az beş fikirle dönün
  • Web sitenizde bir şeyleri değiştirin ve ziyaretçilerinizin bu değişiklikle nasıl etkileşim kurduğunu kaydedin
  • Kar amacı gütmeyen bir kuruluşa hatırı sayılır bir yardımda bulunun (para yardımında bulunabilecek birileri arayın, tanıtımlarını yapın)
  • Bir Wikipedia makalesi yazın veya var olana ciddi bir katkıda bulunun
  • İş arkadaşlarınız, çalışanlarınız veya müşterilerinizle ilgili bilmediğiniz bir şeyleri keşfedin
Yeterli sayıda köstebek tepesi, bir dağ oluşturmak için yeterlidir.

Sunday, January 20, 2013

Avast Raporu - Türkiye Raporu

Avast'ın virüs yoğunluğu raporuna göre Türkiye'nin durumu aşağıdaki gibi.
Sitelere bakıldığında fazla bir yorum gerekmiyor değil mi?


Friday, January 18, 2013

Yazılımın Test Edilebilirliği

Sözleşmelere genelde eklenen ama ne sözleşmeyi yazanların ne de proje takımlarının net olarak bilmediği bir konu olan Yazılımın Test Edilebilirliği ile ilgili bir blog mesajıdır bu.

Aşağıdaki 1. bölüm Wikipedia'dan tercümedir (tercüme sonrasında anlamın korunmasına gayret ettim).
2. bölümde standartlardaki konu ile ilgili açıklamalar verilmiştir.

1) Yazılım test edilebilirliği, bir yazılım ürününün (örneğin bir yazılım sistemi, yazılım modülü, gereksinim veya tasarım dokümanı) test faaliyetini desteklemesidir.
Test edilebilirlik bir yazılım ürünün doğal olarak içinde olan bir özellik değildir ve doğrudan ölçülemez. Aksine, test edilecek ürün ile testin amaçları, kullanılan test yöntemleri ve test kaynakları arasındaki karşılıklı bağımlılıktan doğan dışsal bir özelliktir.
Düşük seviye test edilebilirlik, test eforunun artmasına sebep olur. Bir uç durum olarak, test edilebilirliğin olmayışı yazılımın test edilecek parçalarının gizlenmesine sebep olabilir.

Yazılım bileşenlerinin (modüller, sınıflar) test edilebilirliği aşağıdaki gibi faktörler tarafından belirlenir:
Kontrol Edilebilirlik: Test edilmesi gereken bileşenin bulunduğu durumun kontrolüne ne ölçüde imkan sağlandığı,
Gözlemlenebilirlik: Ara veya nihai test sonuçlarının gözlenmesine ne ölçüde imkan sağlandığı,
İzole Edilebilirlik: Teste tabi bileşenin izole bir ortamda test edilebilme seviyesi,
Sorumluluğun Ayrıştırılması: Teste tabi bileşenin ne seviyede iyi tanımlı, tek bir sorumluluğu olduğu,
Anlaşılabilirlik: Teste tabi bileşenin ne seviyede dokümante edildiği veya kendinden-anlaşılabilir olduğu,
Otomatikleştirilebilmesi: Teste tabi bileşenin testlerinin otomatikleştirilmesine ne oranda imkan sağlandığı,
Ayrışıklık: Paralel olarak farklı test yöntemlerinin ve araçlarının kullanımının gerektiği.

Yazılım bileşenlerinin test edilebilirliği Test-Odaklı Geliştirme ve Test Edilebilirlik için Tasarım yaklaşımları ile artırılabilir.

Gereksinimlerin Test Edilebilirliği: Test edilebilir olması için gereksinimlerin aşağıdaki kriterleri sağlaması gerekmektedir:
Tutarlı,
Tam,
(Tartışmasız bir şekilde) Kesin,
Nicel ("hızlı tepki süreleri" gibi ifadeler olmamalı),
Uygulamada Doğrulanabilir (Test, sınırlı kaynaklar ile sadece teoride değil uygulamada da yapılabilir olmalı).

2) Bu bölümde doğrulama ile ilgili çeşitli standartlardaki Test Edilebilirlik tanımları verilmiştir:
IEEE Std 12207-2008: "Tarafsız ve uygulanabilir bir testin, bir gereksinimin karşılanıp karşılanmadığını belirlemesi ölçütü"


ISTQB (ISO 9126'dan faydalanarak): "Bir yazılımın ürününün, değiştirilmiş yazılımın test edilmesine imkan sağlama kabiliyetidir".

Sunday, January 13, 2013

Fonksiyonel Olmayan Gereksinimler

Sistem mühendisliği ve gereksinim mühendisliğinde fonksiyonel olmayan bir gereksinim belirli davranışlardan ziyade sistemin işleyişini yargılamak için kullanılabilecek kriterleri belirten bir gereksinimdir. Bu açıdan, belirli davranış veya fonksiyonları tanımlayan fonksiyonel gereksinimden farklıdırlar. Fonksiyonel gereksinimler sistem analizi / tasarımında detaylandırılırken, fonksiyonel olmayan gereksinimler sistem mimarisinde detaylandırılırlar.

Genel olarak, fonksiyonel gereksinimler bir sistemin ne yapması gerektiğini belirtirken, fonksiyonel olmayan gereksinimler ise sistemin nasıl olması gerektiğini belirtirler. Fonksiyonel olmayan gereksinimlere aynı zamanda sistemin kalite karakteristikleri de denir.


Fonksiyonel olmayan gereksinimler iki ana kategoriye ayrılabilir:
- İcra Özellikleri: Güvenlik, Kullanışlılık gibi işleyiş süresi içinde gözlemlenebilenler.
- Gelişim Özellikleri: Test Edilebilirlik, İdame Edilebilirlik, Genişleyebilirlik ve Ölçeklenebilirlik gibi yazılım sisteminin durağan yapısına gömülü olanlar.

Fonksiyonel olmayan gereksinimlerden sıklıkla kullanılanlarından bazıları aşağıda listelenmiştir. Daha detaylı tanımlar için ISO-9126: Software Engineering - Product Quality standardına bakabilirsiniz.

Bütünlük
Emniyet
Erişebilirlik
Erişim Güvenliği
Esneklik
Gizlilik
Hayatta Kalabilirlik
İdame Edilebilirlik
Kullanılabilirlik
Kurulabilirlik
Ölçeklenebilirlik
Taşınabilirlik
Tekrar Kullanılabilirlik