Ajánljatok nyelvet/keretrendszert!

Fejlesztés

Sziasztok!

Van egy rendszer, amit szeretnék gatyába rázni (újraírni), ehhez keresem a megfelelő eszközt. A CPU/memória igénye nem túl nagy, és a kód sem olyan hosszú, tökéletesen működik, viszont a jelenlegi állapota zavarja a szépérzékemet, és jó lenne továbbfejleszteni, amit a jelenlegi állapotában nem szeretnék.
A program (nagyon leegyszerűsítve) soros porton fogad adatokat, a belső logika ezt feldolgozza, majd továbbküldi külső egységeknek hálón - http-n, ill. UDP-n. Erről naplót ír, plusz egyéb file-okat is ír/olvas opcionálisan. Van egy GUI-ja, amin megjelenik az állapota, plusz pár beállítás elvégezhető.
Szóval ezt szeretném újraírni, ehhez keresek valamilyen scriptnyelvet, ami gyorsan tanulható, és megoldható rajta minden, ami eddig felmerült.

-Script, mert nem a futásidő, hanem a fejlesztési idő számít (plusz ha valamit s.o.s. bele kell tenni a helyszínen, akkor is fontos)
-Támogassa a soros port kezelését, enélkül nem megy (van pár nyelv, ami csak bizonyos OS-ek esetén tud ilyet, ill. nem supportált, van, amibe utólag hackelték bele)
-Tudjon UDP-t, és tudjon rajta broadcastolni
-Ne nekem kelljen megírni hozzá TCP/IP fölé a HTTP-t, legyen rajta alapból (esetleg libcurl-lal). HTTPS plusz pont, de jelenleg nem kell. Legyen mód arra, hogy saját mezőket felvegyek a HTTP header-be.
-A GUI-t viszonylag kényelmesen össze lehessen hozni, új mezőket/gombokat felvenni, táblázatot megjeleníteni. (Qt talán?)
-Fejleszteni Linuxon szeretek, a production környezet viszont valószínűleg valamilyen Windows lesz, szóval legyen hordozható. (ezen és a soros porton sok nyelv elvérzik)
-Eddig C/C++/PHP/Delphi tapasztalatom van, de egyetemen (és korábban) több másik nyelvvel megismerkedtem és használtam, és nem félek újat tanulni, most pont van rá időm. Azért a C szintaxisú nyelvek jobban bejönnek.
-Később lehet, hogy IP kamera képét is fogadnia kell+feldolgozni. Ha erre is jó (hatékonyan), az plusz pont.

Gondolkodtam azon, hogy alkalmazásszerver jellegű felhasználással a GUI webfelület+AJAX legyen (nyilván a soros feldolgozástól elkülönített thread-en). Lenne előnye, szóval ezen a vonalon is ajánlhattok.

Szerintetek?

  • 3565 megtekintés

( Nyosigomboc v | 2011. 09. 02., p – 01:33 )

Up, trollkaja, flem, stb..
utalok hUPpogni, akkor mar inkabb kiszorok egy kis trollport:

OS X szar, a NetBSD sokkal jobb desktopra.
A GNU/Hurd par even belul megelozi a Win reszesedeset, stb..
vagy lehet Perl vs. Ruby flem is, az meg ontopic is..

--
Always remember you’re unique, just like everyone else.

( Beanie | 2011. 09. 02., p – 01:53 )

És jelenleg miben van ez a rendszer?

Delphi+PHP
Volt egy regi rendszer, aminel kozvetlenul DB-be irta a mert adatokat. Ehhez keszult anno egy Delphis progi (ahhoz volt com portos komponens, es ugye a DB eleres is konnyu). Kesobb valtozott ez a resze, az Oracle-s DB ment a kukaba, kaptunk helyette egy webes interface-t, ide mennek a POSTok. Miutan egy teljesen mas program (amit nem tudunk modositani) kimenetet is be kell kuldenunk, es mar nem volt ido masra (a webes interface is utolso pillanatban keszult el), ezert csinaltam egy parsoros scriptet, ami file-t tud pollozni, es a valtozast kuldi tovabb. Miutan ez a resze mar kesz volt, irtam meg par sort ugyanahhoz a scripthez, es modositottam a Delphis programot, hogy az is mentse file-ba a kimenetet, igy hamar elkeszult ez a resze. Ennek a felepitesnek ugye tobb hatranya is van: elsosorban zavarja a szeperzekemet, masreszt a PHP->Delphi iranyu kommunikacio is csak ganyolassal lenne megoldhato. A Delphitol is meg akarok szabadulni (platformfuggetlenseg ugye), meg az ingyenes verziojaba maceras uj komponenseket telepiteni (meg nem is szeretem a pascalos szintaxist). Egyebkent tokeletesen mukodott elesben, de nem szeretnem sokaig ilyen allapotban hasznalni.

--
Always remember you’re unique, just like everyone else.

python.

ha kell alája valami adatbázisszerűség, érdemes megnézni az sqlite-ot is.
a pyserial win és linux alatt korrektül megy. alapból van benne tcp/udp ill. http/s támogatás, meg még egy csomó minden.
a gui-t én külön processzbe raknám, ott lehet válogatni, hogy mit használjál (web, ha arra alkalmas a feladat; valami qt-alapú cucc, ha kell az interaktivitás; sdl = pygame, ha inkább valami egyszerű, appliance-jellegű felület kell).

ha meg feladod a rapid developmentet, akkor java.

A Javat meg anno, amikor a Delphit valasztottuk, megvizsgaltuk. Az akkori soros tamogatasa nem volt valami korrekt. Ezek szerint fejlodott?
Igazabol erre script nyelvet valasztanek, a python volt az egyik jelolt. A webes felulet a felhasznalas szempontjabol jo lenne (ajax hasznalata mellett), de akkor alkalmazasszerver kell, mert a soros portot egy processnek kell folyamatosan figyelnie.
A kulon processt hogy ertetted, milyen IPC-t ajanlanal a ket resz koze?

--
Always remember you’re unique, just like everyone else.

Én a helyedben a soros port olvasását abban írnám, amiben a legkényelmesebb, az adatokat kiküldeném egy pipe-ba, onnantól jöhet a GUI abban, amiben akarod, és a pipe-ból olvasol.
Ha valahogy "sorokra" tudod bontani az adathalmazt, tolhatod adatbázisba is, akkor akár egy áramszünet után is feldolgozhatod, igaz, ennek aránylag nagy az overheadje (a nagy alatt azt értem, hogy amikor egy 386-oson ezt műveltem anno, akkor ha megindult, darált a vinyó rendesen).

De nagyjából kimondtad a lényeget: a hardver kezelése legyen független a mögötte álló adatfeldolgozástól.

Pont azt akartam írni, hogy legyen egy alacsonyszintű kis service, ami pipeba írja a dolgokat, ami lehet mondjuk C, a többi meg mondjuk Java, vagy ami tetszik. Azért kérdeztem miben van, mert a soros port miatt gondoltam esetleg C-ben, akkor könnyebb lett volna azt refatorálni kigyomlálni.

Kozben atgondoltam a dolgot.
Miben jobb az, ha van egy kismeretu, alacsonyszintu service, ami atadja a soros vonalon vett adatot (gondolom minden platformon hasonlo, de kulon-kulon kod) ahelyett, hogy az is egy teljesen platformfuggetlen scriptben megy? Mar felteve, hogy talalok egy olyan scriptnyelvet, ami teljesen platformfuggetlenul tud com portot kezelni..

--
Always remember you’re unique, just like everyone else.

Separation of concerns. Szerintem rugalmasabb a későbbiekre, és az alacsonyszintű része valószínűleg nem fog elavulni, mert feltételezem a soros porton jövő adatok nagyban nem fognak változni. Most ugye van egy monolitikus Delphi rendszered, ami egy-az-egyben elavult. Anno normális dolog volt a Delphi, ma már senki sem használ ilyet. Ha a hardverközelibb rész eleve C-ben lett volna, most csak a Delphis GUI-t kéne lecserélned. Ráadásul ha változnak az igények, különféle rétegeket építhetsz rá, mondjuk írhatsz rá egy olyan rendszert is mondjuk Javaban, ami Web Services hívásokon küldi valahova az adatot.

Mar felteve, hogy talalok egy olyan scriptnyelvet, ami teljesen platformfuggetlenul tud com portot kezelni..

Tegyük fel, hogy találsz, és megírod abban, örülsz, minden jó. Aztán valamiért ez a scriptnyelv már nem válik be, dobhatod ki az egészet. Ellenben megírhatod mondjuk C-ben a hardverközeli részt. Valószínűleg nem lesz teljesen platformfüggetlen, lesznek ifdefek, de jól kell faktorálni a kódot, hogy elváljon a platformfüggő és a kevésbé platformfüggő rész. Valószínűleg nem lesz nagy program, kevés feldolgozás kell az adatokon, ha kell egyáltalán, szinte csak annyi lesz az egész, hogy áttolja a biteket a pipeon, amiket beolvas. Ezután abban írsz GUI-t, amiben akarsz. Amíg a pipeon a megfelelő formában érkeznek az adatok, addig a GUI-t bármiben leimplementálhatod, ami tud pipeot olvasni, és így máris rengeteget bővültek a lehetőségeid.

+1

Nekem hasonló témakörben egy kis standalone program olvas egy binary stream-ből és összesen annyit csinál, hogy egy minimál validáció és transzformáció után betolja a csomagot egy JMS queue-ba, amit a fő komponens fogad.

Az egyik legjobb döntés volt, hogy így csináltuk.

Nem soronkent jon, de hasonlo:
fixen 16 byte-os csomagok vannak (plusz a port inicializalasakor szokott jonni 1-1 byte 0xff), 19600 bps-el, es a legnagyobb forgalom az 1-2 masodpercen belul 9 db. 16 byte-os csomag, utana fel percig semmi. Szoval ezt a terhelest barmi birja.
Viszont van, amire minel hamarabb kell reagalni, szoval a DB-be iras es onnan feldolgozas nem jo.

--
Always remember you’re unique, just like everyone else.

de akkor alkalmazasszerver kell, mert a soros portot egy processnek kell folyamatosan figyelnie.

Már miért kéne?
Java-ban pl. van a Jetty, ami akár egy nagyon lightweight embedded alkalmazásszervernek is felfogható.

A sorosport kezelésről nem tudok nyilatkozni Javailag, de simán eljátszható, hogy a soros portot egy python script kezeli, és az adatok továbbítja a Java-ban megírt központi résznek, mondjuk HTTP felett.

A kulon processt hogy ertetted, milyen IPC-t ajanlanal a ket resz koze?

HTTP(S).

Lehet fölötte mindenféle protokollokkal játszani (SOAP, JSON, hogy a két legkézenfekvőbbet említsem).

mi Java-ban írtunk enterprise alkalmazást, soros porton beszélgetve a hardverekkel. Tapasztalat szerint nincs baj a java soros port kezelésével, és platformfüggetlen is, amennyiben az rxtx-et használod (http://rxtx.qbang.org)

mivel a soros portot folyamatosan figyelni kell, mindenképp lesz vmi állandóan futó process, ebbe belerakhatsz egy alkalmazásszervert is simán. lejjebb említették a jetty-t java-hoz, na az jó, és akkor lehet JSF2 vagy akármi alkalmazást csinálni.

pythonhoz nem értek, de lehet azzal jársz a legjobban :)

( bocs | 2011. 09. 02., p – 04:01 )

mivel képfeldolgozás, képmegjelenítés is a horizonton van, én mégis csak egy izmosabb eszközt, Qt-javasolnék.
Nehogy később megint újra kelljen írnod a nulláról, mert kiderül, hogy a kraft a scriptnyelvben nem elég.

Az a resze teljesen opcionalis, es ki tudom szervezni kulon programba. Nem is biztos, hogy egyaltalan technikailag lehetseges (real-time alakzatfelismeres, esetleg reszben takarasban levo targyakra).
De ha van valami tamogatas a nyelvben ilyesmire, az plusz pont. Azert irtam.

--
Always remember you’re unique, just like everyone else.

Nem szeretem az ilyen topicokat, hogy miben csináljam (régen én is kérdeztem hasonlót, és megbántam mert csak trollkodás volt), de a képanalízisben pont van tapasztalatom. A realtime képanalízisben is. Nekem az opencv az ami nagyon sokat segített. A vicc az, hogy elkezdtem saját libet írni C-ben, a matematikai modulhoz (fft, konvolúció, egyéb numeikus integrálok, deriváltak,szerencsére akkor még nem volt diffegyenletre szükségem :D). Egy kis idő elteltével rájöttem, hogy a melegvíz feltalálásán fáradozok, ezen lib fejlesztését abbahagytam. Miután elkezdtem használni az opencv-t még gyorsaba is lett a kódom. Lévén nekem se időm, se energiám, se tudásom nem volt még akkor SSE és többiek optimalizálásán. Ráadásul az új opencv (lehet hogy még csak a dev, nekem egyenlőre elég a 2.1) rendelkezik CUDA supporttal. Na az oda tud ám pörkölni a képfeldolgozásban a sebességnek. Tehát a kérdésedre válszolva, egyet választanék a "nagyokból", ami megy, C,Cpp,Java..... Ha az opencv-t akarod használni, akkor C, és Cpp. Bár van python supportja, próbáltam is, de amint egy python függvénynek átadod az opencv kimenetét butális sebességvesztésed lesz. Amíg az opencv-binéris modulja dolgozik, addig kb forma forma a C/Cpp-vel.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

( zoner | 2011. 09. 02., p – 14:26 )

Én ruby-val csinálnám, csak mert azt ismerem. Rendesen karbantartott soros lib-je van és az összes követelménynek megfelel. GUI-ra tk-t legegyszerűbb használni, de van Qt támogatása is.

( pme | 2011. 09. 04., v – 11:21 )

A Tcl/Tk is egy lehetőség, különösen a tcllib-bel együtt.
Win-es környezet a http://www.activestate.com-ról nyerhető.

szerk.: Az activestate-en python és perl környezeteket is találsz sokféle platformra.

( apal v | 2011. 09. 04., v – 11:31 )

Szerintem kb szinte barmilyen szkriptnyelv jo erre a feladatra _ha_ van egy kulon program, ami csinal egy sorosport <-> TCP konverziot. Ezutobbit megirna'm mondjuk C-ben (vagyis elo"vennem, mondvan hogy ma'r megvan). Es akkor effele' tenyleg lehet ma'r a lenyegre (loggolas, GUI, HTTPS, stb.) koncentralni, es nem lesz gond, ha a kedvenc-szkriptnyelv aka'r belassul neha (ld. soros port + adatvesztes), aka'r eleve nem tamogatja a soros port kezelest. A TCP konverziot lehet aka'r helyben is csinalni (AF_UNIX), bar mondjuk ezt a windoz (es az afeletti nyelvek) nem fogja'k tamogatni.