Elektronik çizelge "programlama" bir veri akışı programlama türüdür.
Onunla ilgili bir dil problemimiz var, buna "programlama" dememeliyiz, çünkü programlama dediğimizden çok daha az, ama kesinlikle bir programa veri girmekten daha fazlası.
Veri akışı programlama, uygulamanın bağımsız modüllerden oluşan bir ağ olduğu bir mimarlık ve disiplindir, birbirlerine mesajlar (veriler) gönderirler. Bu model, her sorun için geçerli değildir, yalnızca işleme ağından geçen ve çıkış verileri / akışları üreten bir kaynak veri veya akışın (veya daha fazlasının) olduğu sorunlara uygulanabilir. Aşağıdaki listeye bakın.
Veri akışı programlamanın birkaç türü vardır, bazılarına bakalım:
- E-tablo: giriş numaraları formüllerle, ardından sonuç sayıları ve grafikler ile işlenir. Özel özellikler: giriş zamanı "tek adım" dır, giriş değeri (bileşen) değiştiğinde, işleme grafiğinin uygun kısmı yeniden çalışır ve çıktı üretir.
- Unix borusu: kabuk birkaç program başlatır ve stdout-> stdin'i bağlar. Özel özellikler: sadece boru tarzı bağlantıya izin verilir, grafik tek bir kuyruktur.
- Senkronize yürütme: bir çerçevenin veya örneğin belirli bir frekansta işlenmesini tetikleyen bir saat vardır. Her bileşen saat döngüsünde bir kez çalışır. Video ve ses işleme sistemlerinde örnekler, belirtilen bir kare / örnek hızında çalışırlar.
- Asenkron yürütme: harici bir olay gerçekleşene kadar grafik boştadır. Daha sonra olayı işler, bazı çıktılar üretir (veya oluşturmaz) ve boş duruma geçer.
Sorunuza geri dönün: Bence evet, bir veri akışı uygulamasını bağımsız bir uygulama olarak yayınlamak iyi bir fikirdir. Ben zaten yaptım. İki kez .
Ben ve bir arkadaşım ev otomasyonu için bir prototip DF sistemi oluşturduk. Grafik düzenleyicimiz yok, bu yüzden uygulama kullanıcı tarafından düzenlenemez, bazı parametreler bir yapılandırma dosyasında saklanır, ancak başka bir şey yoktur. Yerel bir yürütülebilir dosyaya derlenen C ++ koduna (bileşen oluşturma ve mesaj tanımlarının bir listesi) "derlenen" bir DF komut dilimiz var. Modüller C ++ sınıflarıdır (diğer sınıflar, sadece sistemimiz hakkında bilgi almak için: Mesaj, Disathcer, Bileşen (soyut), Port (soyut), ConsumerPort, ProducerPort).
Ayrıca, bir DF sisteminin sağladığı avantajlardan şaşırdık : 2 dakika içinde seri sniffer uygulaması yaptık veya yerinde bir test programı yaptık , bu da lambaları birer birer yanıp sönüyor (dokümantasyon yoktu) donanım kimlikleri). MIDI ve joypad bileşenlerini sadece eğlence için yarattık, onunla hafif bir organ da yaptım (bkz. Http://homeaut.com/under_construction/ ).
E-tablolar için yalnızca bir zorluk görüyorum: her sayı ve formül (potansiyel olarak: her hücre) bir bileşen olduğundan, grafiğiniz son değildir. Basit sum () uygulamanıza bir satır eklediğinizde, veri akışı grafiğinin değiştirilmesi anlamına gelir. Yani, grafiği çalışma zamanında "yeniden programlamanız" gerekir, ya da biz buna "metaprogramming" demeniz gerekir. Excel'de bir makro işi yapar, ancak daha sonra veri akışının saflığını kaybederiz.
Çok kötü değil ama mükemmel değil bir çözümüm var. Bir elektronik tablo, PHP arka ucuna sahip bir AJAX uygulaması yaptım. Dikey eksen zaman (gün), çizgiler bileşenlerdir. Girdi (satır kullanıcı tarafından düzenlenebilir), dikey ortalama, yatay ortalama / toplam ve etki alanına özgü bazı istatistiksel hesaplamalar gibi bileşenler vardır. Bununla ilgili tek bir sorun var: bu "tek boyutlu". Sadece toplam ve avg ve istediğim sürece, yeni satırlar ekleyebilir ve şeyleri hesaplayan bileşeni oluşturabilirim. Ancak güçlü bir kısıtlama vardır: sütunlar her zaman günlerdir (günlük verileri sum / avg olarak görüntüleyen hafta ve ay "görünümler" yaptım, ancak yine de tek boyutlu). Gösteremiyorum, işbirlikçi ve 7/24 çalıştırmak için PHP arka uç görevi gerektiriyor, ana bilgisayar sağlayıcım tarafından desteklenmiyor.
Yani, modelim (en iyi şu şekilde tanımlanabilir: "yatay günler") başka tür problemlerle başa çıkamaz.
Bu sorunun nasıl çözüleceği hakkında bir fikrim var: sekmeler .
Excel'de takılı kaldığınızda ve başka bir tablo oluşturmanız gerektiğinde, aynı sekmede farklı bir alan kullanabilir veya başka bir sekme açabilirsiniz. Ayrıca, sekmeler arasında referans vermek rahatsız edici, ilk yöntemi tercih ederim. Bence, sekmeler örtüşmeyen pencereler gibi aynı ekranda görüntülenmelidir.
Her tablonun büyüyen ekseni olmalıdır: dikey, yatay veya sabit. Dikey büyüyen tablolar, tüm sütunların "aynı" formülüne sahip olduğu yatay bileşenlerin sütun bileşenlerine sahip olduğu, sabit boyutlu tabloların herhangi bir elektronik tabloya benzediği satır bileşenlerine (benim gün tabanlı e-tablom gibi) sahiptir.
Dolayısıyla, kullanıcı yeni bir satır / sütun eklediğinde, yeni satır / sütun aynı formüle sahip olacaktır.
Ayrıca, e-tablolarda, 1000 satırım varsa, aynı formülleri 1000 kez kopyalamam gereken şeyden nefret ediyorum. Bir hata kaynağı (bazı satırlarda formülün eski sürümünü tutmak), bellek kaybı (aynı formülü 1000x saklamak).
Belki yanılıyorum ve bu modelde konsept hataları var, ama umarım iyi bir düşündürücüdür.