12 Aralık 2020 Cumartesi

Inbox Zero

"Inbox Zero" kavramı Marlin Mann tarafından ortaya atılmış, e-mail yönetimi ile ilgili bir yaklaşımdır. Amacı e-mail yönetimini doğru yönlendirerek kişilerin çalışma verimini arttırmaktır.


Mann'a göre gelen kutusunda bekleyen posta sayısı sadece posta sayısını değil, bunun yanında kişinin aklında, arka planda süreçli onu yoran bir iştir. Bu yüzden gelen kutusunda bekleyen posta sayısı ne kadar yüksekse, kişinin ilgisi o kadar düşük olur/olabilir. Bunun temelinde algı olarak mail kutusunun bir todo list gibi görülmesidir.


Mann bu problemin çözümü olarak bir öneri sunar. Bu öneride gelen mailler 5 aksiyonla değerlendirilir.
  1. Sil
  2. Yetkilendir/Delege et
  3. Yanıtlama (<=2 dakika)
  4. Erteleme (>2 dakika)
  5. Yapma (<=2 dakika)
Mann'ın e-mail yönetimini verimli bir şekilde işletme konusunda verdiği diğer ip uçları aşağıdaki gibidir.
  • E-mail programınızı açık tutmayın.
  • E-mail yoğunluğunuza göre gelen kutunuzu sadece belirli saatlerde kontrol edin. Yoğun mail kullanımı olan kişilerde saat başları seçilebilir. Daha az e-mail trafiği olan kişilerde ise günde iki defa yeterli olabilir.
  • İlk olarak silebileceğiniz mailleri silin veya arşivleyin
  • Sonrasında başkası tarafından yanıtlanabilecek olan e-mailleri ilgili kişilere iletin.
  • İki dakika veya daha kısa sürede cevaplanabilecek e-maillere hemen cevap verin.
  • Cevabı iki dakikadan uzun ama daha sonra cevaplanabilecek e-mailleri başka bir "yanıtlanacaklar" klasörüne taşıyın.
  • "Yanıtlanacaklar" klasöründeki e-maillere geri dönüş yapmak için gün içerisinde bir saat belirleyin ve o aralıkta tüm yanıt bekleyen maillerinize dönüş yapın.

Bu konu hakkında Mann'ın 2007 yılına ait yaklaşık bir saatlik konuşmasını da aşağıdaki videodan izleyebilirsiniz.


Referanslar:
[1] https://whatis.techtarget.com/definition/inbox-zero
[2] https://flow-e.com/inbox-zero/


7 Aralık 2020 Pazartesi

Cooperative Multitasking

 Bu yazıda cooperative multitasking (CM olarak anılacak) kavramı üzerine bildiklerimi ve gömülü sistemler üzerinde bu yapıya benzer bir çalışma metodolojisi ile nasıl geliştirme yaptığımdan bahsedeceğim.

CM kavramı non-preemptive multitasking olarakta bilinir. Temel olarak görevi taskları sıralı bir şekilde işletmektir. Bilinen modern multitasking yapılarından farkı ise önceliğe göre aktif bir task switching yapmamasıdır. CM yapısında, işlemci aynı anda bir task ile ilgilenir ve o task tamamlanana kadar diğer taskların çalışmasına izin vermez. Bu yapı Windows 3.1x'te kullanılmıştır.[1]

CM yapısı ile çalışacak bir sistemde taskların zamanları önemlidir. Bu yüzden yazılacak taskların süreleri ve gereksinim durumu iyi analiz edilmelidir. Vakit alan bir task önemli bir taskı engellerse bu sistemi verimsiz/anlamsız/zararlı hale getirebilir.

CM kavramını görselleştirmek için aşağıdaki görseli kullanalım. Burada örnek olarak Task A 20ms de bir çalışır ve task aktif olduktan sonra 3 ms boyunca iş yapar. Diğer tasklarda da benzer şekilde çalışma periyotları ve çalışma süreleri tanımlanmıştır.

İlk ve en basit kural çalışma süresi, çalışma periyodundan büyük olmalıdır. Bu ikisi arasındaki fark ne kadar yüksek olursa ilgili taskın işlemciye yükü o kadar düşük olur.



Görselde CM metodu içe çalışan bir yapı verilmiş ve Task A, B, C tanımlanmıştır. Her bir taskın çalışma sürelerine göre işlemler grafikteki gibi verilir. Burada zamanları tek tek inceleyeceğiz.
  • @10. ms Task C çalışır ve 11. ms'de biter.
  • @15. ms Task B çalışır ve 17. ms'de biter.
  • @20. ms Task A çalışır ve 23. ms'de biter. Bu esnada Task A'nın da çalışma periyodu gelir ancak Task A bitmediği için sırasını bekler. Task A biter bitmez 23. ms'de Task C başlar. 24. ms'de biter. Bu kaymadan dolayı Task C'nin bir sonraki başlama zamanı kayar ve Task C 33. ms'de çalışır.
  • @30. ms Task B çalışır ve 32. ms'de biter.
  • @33. ms Task C çalışır ve 34. ms'de biter.
  • @40. ms Task A çalışır ve 43. ms'de biter.
  • @43. ms Task C çalışır ve 44. ms'de biter.
  • @45. ms Task B çalışır ve 47. ms'de biter.
Bu yapıda en önemli konu 20. ms'de yaşanan kaymaların olabileceğidir. Bu yüzden doğru bir düzen içerisinde tasarlanmalıdır. Çok daha uzun sürecek tasklar da olabilir. Bu durumda diğer taskların kritik görevlerinin olmaması önemlidir.

Bu yapıyı kurarken genelde tüm tasklar tek bir zaman sayacı üzerine kurulur ve ilgili zaman sayacını referans alark her bir task çalışma başlangıcını belirler.

Gömülü sistemlerde çalışırken, RTOS kullanmadan geliştirilecek uygulamlarda oldukça faydalı bir yöntemdir. RTOS'lara göre eksik kaldığı bir nokta normalde delay koyarak geliştirilebilecek basit akış diyagramlarını oluşturmak için switch case yapılarının gerekmesi olabilir ancak alışkanlık sağladığınızda fazlasıyla kolaylık sağlayacaktır.

Bu yazı kapsamında interruptsız bir program üzerine konuyu anlattım. Ek ve özet bilgi olarak bu yapılar çalışırken çalıştıracağınız interruptlar ile de tam gerçek zamanlı tasklar çalıştırabilirsiniz. Kurgulanacak bu yapıda yukarıda verilen tasklar interruptlar tarafından bölünür ve sizin hem interrupt yapınız hem de ana döngü yapınız sağlıklı bir şekilde çalışabilir.

Ana döngü içerisinde yavaş toplanacak veriler, haberleşme değerlendirme algoritmaları, dosya okuma/yazma yapıları vs. geliştirilebilir. Interruptlar içerisinde ise hızlı tepki verilmesi gereken giriş/çıkış yapıları, kontrol algoritmaları, periyoda bağımlı algoritmalar vs. çalıştırılabilir.

Umarım faydalı olur.

Referanslar

[1]. https://en.wikipedia.org/wiki/Cooperative_multitasking

CAN Bus Frame Tipleri

Yazıya başlamadan önce CAN Bus temelleri ve mesaj yapısının temellerini incelemek için bu linkte yer alan blog yazısını inceleyebilirisiniz ...