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?
- 14505 megtekintés
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)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Ó, ez jópofa, köszi! :)
- A hozzászóláshoz be kell jelentkezni
sub
illetve 3. opciónak lighttpd+PHP5(fastcgi) esetleg?
- A hozzászóláshoz be kell jelentkezni
Esetleg lighttpd helyett nginx.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Barmilyen $RANDOM szempont alapjan jobb a perl vagy a node mint a php... :-) #troll
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
-1 a #troll tagra
+1 egyébként
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Subscribe
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 :)
- A hozzászóláshoz be kell jelentkezni
é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 :)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
"Nagyjabol egyedul a Java az, amit erosen nem ajanlok a hardverre."
Van valamilyen konkrét tapasztalatod vele?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
Gondolom a Java appok alat memoriafogyasztasa fugg attol is, hogy mennyi memoria van a gepben.
- A hozzászóláshoz be kell jelentkezni
http://en.wikipedia.org/wiki/Embedded_Java
--
NetBSD - Simplicity is prerequisite for reliability
- A hozzászóláshoz be kell jelentkezni
Egy kis olvasnivaló (raspberry pi + embedded java)
http://files.meetup.com/1401221/CLE-JUG-Java-Embedded-Raspberry-Pi-v1_0…
- A hozzászóláshoz be kell jelentkezni
Itt pedig egy jónak tűnő online kurzus...
https://apex.oracle.com/pls/apex/f?p=44785:145:0::::P145_EVENT_ID,P145_…
- A hozzászóláshoz be kell jelentkezni
Oracle + "jónak tűnő" = lol
- A hozzászóláshoz be kell jelentkezni
merthogy?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Á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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Elhiszem, ha te mondod :-)
De nyilván lenne költséghatékonyabb megoldás is.
Fuszenecker_Róbert
- A hozzászóláshoz be kell jelentkezni
É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.
- A hozzászóláshoz be kell jelentkezni
es tudjak ezt a jit-et arm-ra is? ;)
--
NetBSD - Simplicity is prerequisite for reliability
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Subscribe
- A hozzászóláshoz be kell jelentkezni
[subs]
- A hozzászóláshoz be kell jelentkezni