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?
Hozzászólások
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.
Ó, ez jópofa, köszi! :)
sub
illetve 3. opciónak lighttpd+PHP5(fastcgi) esetleg?
Esetleg lighttpd helyett nginx.
Szeretnek kikerulni a mindennapokbol, ezert a php-t hanyagolnam... Ezenkivul a szukos eroforrasok miatt akar a perl, akar a nodejs jobb valasztas mint a php.
Barmilyen $RANDOM szempont alapjan jobb a perl vagy a node mint a php... :-) #troll
--
-1 a #troll tagra
+1 egyébként
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
Subscribe
+1
+1
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
Egyreszt mar megvan a lapka, igy a hardwer nem kerdeses. Masreszt az elkeszult software github-on elerheto lesz, amint megfelo formaba kerul, igy talan mas raspberry pi user is hasznat veszi majd, ezert mindenkeppen olyan kompaktra szeretnem csinalni, amennyire csak lehet.
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 :)
érdemes ránézni a pythonra mindenképpen, de ha több ilyen pi-re épülő projektet tervezel akkor meg főleg. Nem véletlenül kezdték el az utóbbi években a nagyobb külföldi egyetemek is pythonon oktatni a programozást :)
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.
--
Nem, a JS a TypeScript-től lett oop szemléletűbb. :)
Érdekes, a kényszert nem érzem, valószínűleg azért mert erősen preferálok az async apikat, de így legalább a 3rd party libek is megfelelnek a preferenciámnak. Hát, kinek mi.
A kerdes nem egeszen errol szolt. Lehet, hogy nem volt egyertelmu, de az lett volna a kerdes, hogy Pi-re melyik nyelvben eredemesebb fejleszteni.
A masik pedig az, hogy a nodejs sem egy mindenhato csodafegyver. Van amire alkalmas, es van amire nem. Feladat fuggo.
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.
--
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.
--
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.
Nyilván... Épp ezt mondom én is.
Viszont a W5100-at konkrétan nem ismertem, kösz a tippet, még jól jöhet!
Egyébként pont azon gondolkodtam, hogy az arduino és társainak mi értelme van? Nekem nagyon gyenge hw-nek tűnnek, cserébe viszont a raspberry pi és társaihoz képest
elég drágák.. talán a sok szabad IO port?
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.
"Nagyjabol egyedul a Java az, amit erosen nem ajanlok a hardverre."
Van valamilyen konkrét tapasztalatod vele?
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.
--
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?
Gondolom a Java appok alat memoriafogyasztasa fugg attol is, hogy mennyi memoria van a gepben.
http://en.wikipedia.org/wiki/Embedded_Java
--
NetBSD - Simplicity is prerequisite for reliability
Egy kis olvasnivaló (raspberry pi + embedded java)
http://files.meetup.com/1401221/CLE-JUG-Java-Embedded-Raspberry-Pi-v1_0…
Itt pedig egy jónak tűnő online kurzus...
https://apex.oracle.com/pls/apex/f?p=44785:145:0::::P145_EVENT_ID,P145_…
Oracle + "jónak tűnő" = lol
merthogy?
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.
Á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
Hogy érted azt, hogy Fermi szintnyi? A Fermi nívó nem igazán jó szerintem arra hogy különbséget kifejezz, inkább viszonyítási alapnak lehet jó... Számomra nem világos pl ebből a mondatodból, hogy kicsit vagy nagyot értesz ez alatt.
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
Az az igazság, hogy van az interneten pár alkalmazás, ahol használnak JS-t, ráadásul úgy, hogy azt folyamatosan fejlesztik is! Tudom, hogy nehezen hihető, de igaz!
--
HUP Firefox extension
Elhiszem, ha te mondod :-)
De nyilván lenne költséghatékonyabb megoldás is.
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.
es tudjak ezt a jit-et arm-ra is? ;)
--
NetBSD - Simplicity is prerequisite for reliability
A kérdés teljesen jogos.
Megnéztem a V8 forrását, van arm és arm64 könyvtár is.
Fuszenecker_Róbert
Amellett V8 by design nem tud nem jittel működni. Jitet vagy semmit.
Egyébként chromeos és android miatt is létszükséglet az arm support.
Subscribe
[subs]