RaspberryPi-n Perl, vagy Node.js?

Szkriptek: Python, Perl, Bash, ...

Udv,

Egy raspberry pi-n futtatott cli-s apphoz szeretnek webes frontendet gyartani, azoban a megvalositasban mar ott hiba csuszott, hogy nem tudok valasztani ket nyelv kozul.Perl

pro:

  • regen perl-eztem, nem artan felfrissiteni
  • szivesen kiprobalnam a mojolicio.us-t
  • alapbol ott van a pi-n

contra:

  • fuggosegek kezel(hetetlensege|ese)
  • a mojo mint framework, vajon nem tul robosztus-e a kis pi-hez

Node.js

pro:

  • fuggosegek egyszeru kezelese
  • lehelletnyivel jobb OOP
  • manapsag divatos, igy talan megeri tobbet foglalkozni vele

contra:

  • talan nem mindenki akarja felrangatni a nodejs csomagokat a pi-re
  • vajon nem lesz lassab pi-n mint egy perl-es megoldas

A fenti listat csak gondolat ebresztonek irtam, a teljesseg igenye nelkul.

Ti mit valasztantok, es miert?

( zsoltt | 2014. 07. 10., cs – 21:07 )

Subs

(Engem is a raspberry+node.js érdekel egy jövőbeli projektem kapcsán, úgyhogy kíváncsi vagyok kinek milyen tapasztalata van)
Amúgy érdekes, én épp a node.js -t gondolnám gyorsabbnak (hasraütés alapján)

Az egyik nodebp meetupon volt szo egy projectrol, ahol a pi-t hazi sorfozeshez vetettek be, ott nodejs-t hasznaltak rajta.

http://hekike.github.io/BrewingWithNodeSlides/assets/player/KeynoteDHTM…
https://www.youtube.com/watch?v=Dk8Tj1P-Ugc

Ez persze nem jelenti azt, hogy a nodejs a legjobb megoldas, csak azt, hogy mukodik.

( Crayon | 2014. 07. 10., cs – 21:56 )

sub

illetve 3. opciónak lighttpd+PHP5(fastcgi) esetleg?

PHP nem olyan rossz. Bár rPi-n nem használtam még.
De openwrt-s routereken igen. És teljesen működő megoldás.
Akár Perl akár PHP érdemes óvatosnak lenni a keretrendszerekkel, mert a RAM fogyasztás bizony meg tud ugrani.
node.js-el nincs tapasztalatom.. De nekem is rajta van a bakancslistámon.

### ()__))____________)~~~ #################
# "Ha én veletek, ki ellenetek?" # E130/Arch

( royal v | 2014. 07. 11., p – 09:44 )

Amióta a cubieboard2 elérhető, azóta inkább azt használom, azon szinte bármi elfut normálisan. Ha még csak tervezed az eszköz beszerzését, akkor fontold meg ezt az irányt is, mert akkor nem annyira kell erőforrásra optimalizálnod :)

--
http://eVIR.hu
Elektronikus Vállalatirányítási Információs Rendszer

Ha github-ra is fel akarod tenni, akkor már inkább node.js. A perl nagyon jó nyelv, de talán pont a raspis közösség inkább a "modernebb" megoldások felé hajlik. Pythonban nem gondolkoztál? Azt alapból támogatja a raspi, nagyon könnyű benne dolgozni, és eleve az a közösség egyik kedvence.

Mi C/PHP-ről indultunk anno (tudom, hogy perverz), most egy új projekthez viszont már csak Pythont használunk, mert az jó, default rajta van és mindent tud. Node.js is a listán volt, mint opció, de pont az általad is említett telepítési igény miatt nem foglalkoztunk vele aztán.

Na a python pont az a nyelv, amivel meg sohasem foglalkoztam egy betut sem. De akkor a pi miatt lehet, hogy felkerul a listamra. Egyebkent azt tervezem, hogy a feluletet angularjs segitsegevel rakom ossze, igy viszonylag konnyu lesz backended cserelni mogotte, es eloszor megirom nodejs-ben (ezzel tudok a leghamarabb vegezni), aztan perlben is (valamennyire meg emlekszem), aztan ha nagyon unatkozom, akkor johet a tobbi (python, ruby, go, stb :)

En azt mondom, inkabb valassz ki egy nyelvet, es azt tanuld ki jol, a tobbit inkabb csak olvasni erdemes tudni.

Nalam ez a nyelv egyebkent a Ruby lett, ugy, hogy korulbelul masfel evig a Python volt rajongasom targya. A Python a maga nemeben egeszen kivalo nyelv, viszont objektum-orientaltsag szempontjabol hagy nemi kivannivalot maga utan, itt-ott megerzodik rajta, hogy valahol a melyben azert C sziv dobog. A Rubynal ellenben sosem volt ilyen erzesem, nagyon szepen elfed mindent, amit csak lehet, egy magasan fejlett objektumorientalt nyelv felol jove a szintaxis nem kelti benned azt az erzetet, hogy scriptnyelvvel van dolgod,

Nyilvan, mivel scriptnyelv, egy picit kevesbe tipusos, mint mondjuk egy C# vagy egy Java, de boven jobban kezeli a tipusokat, mint egy PHP.

A Node/JS -sel alapvetoen az a problemam, hogy belekenyszerit az esemenyvezerelt programozasi modellbe, ami sokszor jo, sokszor viszont teljesen felesleges, foleg, mert - szerintem - szuksegtelenul bonyolult kodokat eredmenyezhet. Raadasul a JS nem lett sokkal OOP szemleletubb attol, mert kapott egy rendszerkozelibb runtime-t.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

De rossz a kerdes. Nincs olyan, hogy Pi-re miben erdemes fejleszteni. Olyan van, hogy mi a feladat, es milyen nyelvben erdemes elkezdeni. Aztan jon az, hogy ez mukodhet-e Pi-n. Ugyanis a nyelvvalasztas elsosorban feladatfuggo, es nem celeszkoz-fuggo.

Arrol nem beszelve, hogy ha nem erosen rendszerkozeli es/vagy performanciaigenyes appot akarsz osszerakni, akkor kb. mindegy, miben kezded el irni. Egy raspberry eleg eros ahhoz, hogy egy egyszerubb appot elfuttasson akar Rubyban is.

Mondok peldat: ha az a feladat, hogy egy webes feluleten kell kiszolgalni cuccokat, peldaul meresi eredmenyeket, barmilyen celszeru is beagyazott rendszerekre C-ben fejleszteni, nem biztos, hogy abban kezdenem el. Ha a mereseket nem feltetlen on-demand kell elvegezni, hanem automatikusan, akkor egy kis C modul megcsinalna a mereseket, lerakna egy CSV-be, es egy Ruby script pedig adna hozza egy fancy reszponziv webes feluletet, mondjuk egy WEBrick servletkent. Ha a mereseket on-demand kellene elvegezni, akkor pedig a C-ben irt lekerdezo cuccot olyan CGI-kent irnam meg, ami csak egy JSON-t kop vissza, a HTML+jQueryben irt webes felulet pedig csak lekerdezgeti a CGI-t.

Szoval, feladatfuggo.

Nagyjabol egyedul a Java az, amit erosen nem ajanlok a hardverre.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Najó, de ha az a peremfeltétel, hogy olyan az eszköz, hogy nincs rajta ruby?
Vagy mondjuk 8kb ram van? Abból már (szerintem, nem próbáltam) lehet http -t kiszolgálni, de nem rubyval.
Életszerű lehet ez a peremfeltétel, ha az egész rendszer sorozatgyártásra készül, és fontos az olcsó hardver.

Igen, eletszeru. Ezzel egyutt fontosabb az, hogy a feladat implementalhato legyen. Ugyanis mig a nem megfelelo eszkozt konnyu kicserelni egy, a feladathoz megfelelobbre, addig egy rossz nyelven fejlesztett projekt atultetese sokkal nagyobb macera.

Egyebkent 8kb RAM-mal meg perl-bol se igen szolgalsz ki HTTP-t, az a tisztan C alapu cuccok terulete. Viszont manapsag mar a RAM egyaltalan nem draga, a fos szar kinai SOHO routerek se igen mennek 32 MB memoria ala, pedig azok aztan tenyleg olcso hardverek.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Nem ritka a 16 Mbyte - lásd például az Asus némely eszköze, vagy a Linksys WRT54G korai szériái az openwrt által támogatott routerek listájában -, de ott már valóban nagyon kell matekozni.

Ami meg a Ruby-t illeti: annó a Redmine feladatkezelőt néztem Raspberry Pi-n (256 Mbyte RAM mellett), reboot utáni első betöltés kb. 2 perc. Utána már 3-5 másodperc.

8k-ba semmivel se fogsz beleférni. Arduino + W5100 esetén a nagyságrend stimmel (a W5100 sok terhet levesz a válladról), de ott a kapcsolatok száma lesz erősen korlátozó. Illetve ott ugye php/ruby/python-szerű dolgokról nagyon nem kell álmodni, legtöbbször statikus oldalak mennek ki.

Legtöbb arduinonak nyílt a hardvere is, azaz csinálhatsz magadnak saját arduinót, vagy hatékonyan sorozatgyárthatod ha úgy adódik, nincs vendor lock-in, szerintem nagy mennyiségben így olcsóbbra kijöhetsz.
Amellett sok arduino úgy tudom kevésbé érzékeny arra ha túl sok voltot kap, mint egy raspberry, így könnyebben lehet kísérletezgetni.
Amit arduinora írsz, az közvetlenül a vason fut, könnyebb realtime dolgot csinálni, ha szükséges (tudom, létezik rtlinux is, de az van amikor ágyúval verébre lehet).
Arduinora bármit ráköthetsz, és gyakorlatilag realtime feldolgozhatod az inputot. Van aki pont azért rak össze raspberryt arduinoval, mert sokkal tágabbak az input lehetőségek.

Lehet, hogy a hw gyenge, de Raspberry Pi már fagyott le Raspbiannal, viszont Arduino még nem állt fejre. Egyébként nem kizárt, hogy valami pillanatnyi hw probléma volt.

Illetve ne csak Arduino-ban gondolkozz, a Texas Instruments-nek vannak combosabb lapjai.

Ami még az Arduino (és társai) mellett szól: energiatakarékosabbak, ha jól csinálod. Persze itt is igaz az, ami mindenhol: használd a legmegfelelőbb eszközt, legyen az Pi vagy Arduino.

Konkret nincsen, de tekintve, hogy az ilyen tipusu hardverekhez mekkora mennyisegu memoria szokott jarni, plusz hozzaveve az atlagos Java alkalmazasok memoriaigenyet (es itt nem a "sok memoria kell a javanak" cimu eposzra gondolok, egy tok atlagos jol megirt Java app is 64-128M kozott siman megeszik, alaphangon) az jon ki az egyenletbol, hogy nem a legjobb otlet. Persze, ez pusztan a jozan paraszti esz szulte logika, meg nemi tapasztalat a Java alkalmazasok korul.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Azt tudjuk, hogy 512M van a B málnában.
A kérdés az, hogy mennyit foglal el parancssoros OS, nagyjából a többi mehet a javanak.
Ha jól értem az okoskodásod, akkor szerinted az OS több, mint 400M-t foglal, és így nem marad a javanak.

Valakinek van RaspberryPi B -je és meg tudja mondani, hogy a parancssoros OS -nél mennyi szabad memória marad?

( andrewjsi | 2014. 07. 11., p – 17:27 )

Mojolicious-t csak ajánlani tudom. PI-hez is. Nem kell hozzá semmi extra. El kell számolni háromig, amíg beindul, de ha már fut, akkor elég gyors.

( uid_720 | 2014. 07. 26., szo – 23:40 )

Állítólag a JS JIT-ek mindenféle fekete mágiát végeznek, hogy gyorsak legyenek. És sikerül is nekik.

Kérdés, hogy szempont-e a kód karbantarthatósága. Ha igen, akkor ... sosem gondoltam, hogy valaha ezt mondom: szerintem a JS egy fermi-szintnyivel jobb megoldás.

Fuszenecker_Róbert

Kicsit.

Nem szeretem se a Perlt, se a JavaScriptet, szerintem mindent megtettek a feltalálók, hogy mindkettőben nehéz legyen karbantartható kódot írni.

A TypeScript jelenthetne megoldást, de ehhez az kell, hogy minden eddig megírt JavaScript libraryhez legyen definíciós fájl (.d.ts), van ilyen kezdeményezés, de én még pihentetem a témát 5-15 évig.

Fuszenecker_Róbert

Én is tartottam ettől, mármint a .d.ts -ek hiányától, de a gyakorlatban ez úgy néz ki, hogy inkább nice to have ha van valamihez, a lényeg hogy saját projekten belül typesafe minden.
Amúgy van tsd nevű csomagkezelő a .d.ts -ekhez, amivel könnyen kiderül, hogy van-e, nem kell túrkálni.