-
Mobilarena
JavaScript != Java (A JavaScript nem összekeverendő a Javával, két különböző programozási nyelvről van szó!)
Új hozzászólás Aktív témák
-
inf3rno
nagyúr
Köszönöm mindkettőtöknek! Azt hiszem átnézem a licenszeket és árazást is mielőtt döntök. Sokszor csak akkor ingyenes valami, hogyha nem üzleti célhoz használom. Nem tudom a vue esetében mi a helyzet ilyen téren.
szerk:
Datatables is ingyenes MIT licensszel. Úgy tűnik a support, ami pénzbe kerül. [link] A Vue szintén MIT. [link] -
inf3rno
nagyúr
Milyen könyvtárat ajánlotok most kliens oldalra? Ilyen klasszikus dolgok kellenek, hogy táblázatok, egy-egy rekord szerkesztése, kb. mint egy ügyviteli rendszerben, semmi extra, de azért ne a 90-es évek table kinézete. A szerverről JSON-LD-t küldenék, vagy max JSON-t valami REST-es megoldással. Ha lehet ne legyen nagyon elrugaszkodott, nem vagyok oda a túlzott absztrakcióért.
-
inf3rno
nagyúr
válasz
TheProb
#5645
üzenetére
Ha megnézted volna, a konzolt, akkor látszott volna benne, hogy a getElementById null-t ad vissza, ami meg csak azért lehet, mert rossz id-t adtál meg.
Ha most tényleg jól megy, akkor ez lehet az 1.0. Ha van kedved tovább fejleszteni, akkor javaslom, hogy ahelyett, hogy az input-okat járod be az ellenőrzésnél, csinálj 2d tömböt a tartalmukból, és azt járd be. Ez elsőre plusz munkának tűnik, de így közvetlenül a "model"-en tudsz dolgozni, és cserélni tudod, hogy honnan és hogyan olvasod be azt. Következő lépésnek be lehetne tenni egy olyan, hogy az input.onchange eseménynél olvasod be minden cellából az értéket, a 2d tömbödbe, ahelyett, hogy gombnyomásra tennéd ezt. Így a gomb teljesen feleslegessé válna, helyette minden változásnál futtathatnád az ellenőrzést automatikusan. Ez mondjuk lehetne a 2.0. Következő lépésnek betehetnél két táblázatot ugyanahhoz a model-hez, és az lenne a feladat, hogy szinkronban tartsd őket. Szóval ha az egyikben változik egy cella tartalma, akkor a másikban is változnia kéne, ez már egy komolyabb data binding, lehetne 3.0. Utána csinálhatnál olyat, hogy külön ablakban van a két táblázat, és úgy tartod szinkronban a cellák értékeit, ez lehetne 4.0. Nagyjából ennyi amit ki lehet hozni a témából. Gondolom egy kis fantáziával még képeket is lehetne generálni a számok alapján, stb.
-
#5617
inf3rno
nagyúr
Sk8erPeter
#5616
inf3rno
nagyúr
válasz
Sk8erPeter
#5616
üzenetére
"Ha nem baj, megfordítanám a dolgot: arra mutathatnál nekem olyan általánosítható bizonyítékot, hogy minden esetben gyorsabb összeállítani egy gigarendszerben - annak összes függőségével, aktuális használati esetnek megfelelő konfigurációjával, stb. - egy valóban komplett tesztkészletet egy kisebb/nagyobb feature időre történő fejlesztéséhez, mint TDD/BDD aktuális alkalmazása nélkül azt elkészíteni."
Nem tudok ilyesmiről, de nem nagyon szoktam statisztikák után nyomozni. A kezdeti fejlesztési idő valamivel lassabb, a bug sűrűség viszont sokkal kisebb. Egy tanulmány szerint kb 15-35%-al több időt kell beleölni a projektbe, és valahol 40-90% közötti mértékben esett vissza a release előtti bug sűrűség, máshogy fogalmazva, kevesebb, mint fele annyi bug volt. [link] A 15-35% idő többlet a 2x annyi debug-nál tapasztalatom szerint bőven visszajön. SO-n volt ilyesmi kérdés. [link] Ha ennyire izgat a téma, akkor utánakereshetnél te is, nincs kedvem olyan dolgokra pazarolni az időmet, amiből nem tanulok semmit, max megnyerek egy vitát. A többi már tényleg nagyon off.
-
inf3rno
nagyúr
Ja, ezt én is észrevettem, de engem nem zavar. A grunt-ot én nem szeretem, inkább a configuration by code híve vagyok, amit gulppal meg lehet csinálni. Sokkal rugalmasabb. Ha van kedved összeszórhatnál valami hasonló környezetet makefile-al, kíváncsi vagyok, hogy mi a különbség.
-
inf3rno
nagyúr
Neki valamilyen deprecated modullal sikerült csak megoldania. Egyébként ja, nagyjából ennyi a történet, de gondoltam, akkor már megcsinálom rendesen olyan formában, amire lehet később hivatkozni, ha felmerül ugyanez a kérdés, meg belövök hozzá teszt környezetet sourcemaps, el, meg minden ilyesmivel. Így is, úgy is kelleni fog nekem a master branch saját projektekhez, a babel-es branch meg nem sokban különbözik, úgyhogy belefér az időmbe, hogy pár órát annak az összevakarására is rászánok.
-
inf3rno
nagyúr
Életemben talán az az első sor, amit ES6-al írtam, annyi volt a cél, hogy legyen gyorsan valami ami ES6 featureöket használ, valid, és tudok hozzá tesztet írni. Sosem használtam babel-t, és nagy valószínűséggel nem is fogok. Az egész babel-es branch-et amúgy nektek szórom össze.
-
#5603
inf3rno
nagyúr
Sk8erPeter
#5602
inf3rno
nagyúr
válasz
Sk8erPeter
#5602
üzenetére
Én jelenleg hobbi projekteknél fejlesztek így, most éles projektjeim nincsenek. Régebben éles projekteknél még nem ismertem ezeket a technikákat, személyes tapasztalatom annyi, hogy volt olyan projekt, aminél utólag írtam meg a teszteket, és az SQL-ek felében volt kisebb nagyobb hiba, amik nem derültek ki azonnal, mert csak ritkán használt útvonalakról volt szó.
Tudok olyan multiról, ahol TDD + SOLID + OOP alapvető, és a backend-et így fejlesztik, nem véletlenül írtam. Nem hinném, hogy nyugis munkahely lenne, inkább csak elvárják a minőségi kódot, meg egy méret (pár ezer sor) felett széthullik a szemét, amit tesztek nélkül fejlesztesz. A GUI-t nem feltétlen éri meg e2e tesztekről indulva fejleszteni, de azért érdemes lehet bedobni párat a fontosabb feature-ök ellenőrzésére, ha nem is minden apróbb hülyeségre. A DDD egy projekt méret felett éri meg jobban, mint a monolit, én személy szerint ezzel nem értek egyet, próbálom kisebb projekteknél is alkalmazni. Arra, hogy a TDD/BDD többlet idővel járna mutathatnál valami bizonyítékot, mert pont az ellenkezője igaz. Debugra összességében több idő megy el, mint arra, hogy a teszteket előre megírd, és az alapján fejlessz. Persze ha nem veszed komolyan az egészet, vagy nem fotnos a minőség, akkor nyugodtan fejleszthetsz tesztek nélkül is. -
inf3rno
nagyúr
Sikerült közben a source maps-et is részlegesen működésre bírni: [link] Karma-val megy, sima browserify-olt forráskóddal is megy, egyedül jasmine nem jelzi a manuális HTML reporterével. Talán ki lehetne keresni, hogy karma hogyan csinálja, passz. Ami probléma, hogy ugyanezt a test bundle futtatásos megoldást használom babel-nél nodejs tesztelésre jasmine-el. Szóval nodejs-el nincs lehetőség normális debug-ra ha babel-t is használtok.
Nem tudom, hogy van e más lehetőség arra, hogy átfordítsam a kódot egyesével fájlonként, majd jasmine-el teszteljem. Elvileg az egész teszt mappát át kellene fordítanom valami babelify szerű libbel, aztán átnyomatni jasmine-en. Ehhez valami gulp-jasmine, vagy hasonló kellene, ami képes file stream-ekkel dolgozni. Megnézem, hogy van e ilyen. Ha igen, akkor ez a része megoldódott, és egyedül csak a manuális böngészős tesztelés nem fog menni HTML jasmine reporter miatt, ami talán nem egy nagy veszteség, karmával megy, böngészőben megy, ha betöltjük a bundle-t, egyedül ez a reporter nem tölti be a source map-et.
-
inf3rno
nagyúr
válasz
DNReNTi
#5599
üzenetére
Van még egy rakás másik editor is [link] pl aloha egész jónak tűnik, CK sem rossz egyébként. Ezeknél legtöbbször ott szokott a gond kezdődni, amikor egyedi dolgokat akarsz beletenni valamilyen pluginnel. Ha semmi ilyesmi nem kell, akkor bármelyik jó. Ha később kell, akkor meg még mindig kicserélheted. Van itt directive alohára: [link] meg ck-ra is [link] [link]
-
inf3rno
nagyúr
Szvsz a TDD nem advanced dolog, hanem alapvető, ha fejleszteni akarsz. Ha nem ismered, nagyjából arról szól, hogy először a tesztet írod, utána meg az implementációt, mindezt kis kód részletekben. Így a végére a kód nagyjához lesz automatizált teszted. Menet közben is hasznos, mert a hibák azonnal kiderülnek, és nem kell utánanyomoznod órákat debug-al, hogy hol hasal el a kód. Én már inkább a BDD fele hajlok, annál először szövegesen írod le, hogy mit akarsz, aztán azt fordítod át tesztekre. Így a teszteket bármikor kicserélheted, úgy, hogy a szöveg változatlan marad. Ez sokkal rugalmasabb, mint a TDD, pl ugyanazok alapján a leírások alapján egy csomót azonos képességű eltérő klienst tudsz fejleszteni, esetleg eltérő API-kat kipróbálni, és így tovább.
-
inf3rno
nagyúr
Megértelek, a dev környezet kiépítésére sajnálom leginkább az időt. Inkább leülök olvasni, vagy kódolok, minthogy erre menjenek el napjaim. Nekem nem tűnik annyira szélesen támogatottnak ez a sourcemap dolog, de egyelőre még csak firefox-ban néztem meg, elképzelhető, hogy más böngészőkben jobb a helyzet. Az elvet sem pontosan tudom, ami mögötte van, pl hogy lehetséges e több fájlt és azok kódjait betenni egy sourcemap-be, az is kérdés. Jelenleg csak a babelhez meg a minifyolt változathoz kellene, máshoz nemigen, szóval meg tudnám oldani nélküle is. Amit idáig összetákoltam dev környezetnek karmával meg nodejs-el az egész jó, át fogok térni rá a projektjeimnél, fejlettebb, mint amit előtte toltam.
-
inf3rno
nagyúr
Próbálkoztam sourcemaps-el, de nem nagyon lehet ráhúzni. Nekem legalábbis nem sikerült egyelőre. Te hogyan debuggolsz babellel? Én egyelőre sima browserify + ugify-al próbáltam sourcemaps-et a gulp-sourcemaps-el, de csak a bundle tartalmát látom firebug-ban, a forrás fájlokat nem, illetve hibánál a sor is a tömörített fájlra vonatkozik, szóval mindig 1. Így egyáltalán nem használható debug-ra. Még próbálkozom. Ha mégis összejönne, akkor megpróbálom babel-re is.
Láttam, hogy van karma-cucumber, szóval elvileg cucumber-el is lehetne tesztelni, nem muszáj a jasmine. Majd megpróbálom azt is, mert nekem a BDD szimpatikusabb, mint a szimpla TDD, amit jasmine jelenleg támogat. Furának tartom, hogy azt írják jasmine dokumentációban, hogy BDD keretrendszer, amikor köze nincsen hozzá.
-
#5590
inf3rno
nagyúr
PumpkinSeed
#5589
inf3rno
nagyúr
válasz
PumpkinSeed
#5589
üzenetére
Szerintem az igazi akkor lesz, ha a felhasználóknak is alap lesz, hogy fent van a gépén ugyanúgy, mint a java. Kicsit bele kellene reklámozni, de megéri, mert nem csak java-t lehetne így fejleszteni platformfüggetlenül, hanem bármit.
Ha valaki csodálkozna, hogy hogy jön ez ide, docker-en van már elég régóta nodejs is. [link]
-
#5588
inf3rno
nagyúr
PumpkinSeed
#5585
inf3rno
nagyúr
válasz
PumpkinSeed
#5585
üzenetére
Közben átgondoltam, hogy mire jó a Docker. Bár nem vagyok benne biztos, hogy tényleg így működik.
A docker elvileg egy mini oprendszer az aktuális oprendszer felett. Minden oprendszer fölé ugyanazt teszi fel. A programok ezen a standard interface-en keresztül kommunikálnak, és nem látják a tényleges oprendszert. Tehát ha csinálsz egy docker image-t, azt bármelyik oprendszerre feltelepítheted, amin ott van a docker. Ez nyilván azt hozza magával, hogy webfejlesztésre nagyon jó, asztali app fejlesztésre pocsék, mert manapság egyáltalán nem gyakori, hogy a felhasználó gépén fut a docker, kivéve, ha Linux-os hozzáértő emberről van szó. Nyűg külön telepíttetni olyan Win felhasználókkal, akik analfabéták a géphez, márpedig ha ilyen a célközönséged, akkor próbálod minimumra venni a next-ek számát is, nehogy valamit elállítsanak. A webfejlesztésnél azért lehet jó, mert nem kell szerver meg oprendszer kompatibilitást tesztelni, elég csak felszórni az imaget egy container-be, aztán megy. Ennyi. Asztalinál is ez lenne az előnye, valszeg ezért el is fog terjedni.
A VM egész máshogy működik, az eltérő oprendszereket szimulál, szóval azon tudod tesztelni, hogy eltérő oprendszerekkel hogyan működik az alkalmazásod. Az asztali fejlesztés annyiból rosszabb vele, mint a docker-el lenne, hogy több környezetre kell tesztelni, és többször megírni a kód egy részét. A java ezen segít valamennyit, kb ugyanazt csinálja, mint a docker, elfedi az eltéréseket. A webfejlesztés kb ugyanolyan, mint docker-el, annyi, hogy a szerver gépet szimulálod vele, így az oprendszered lehet valami tök más is, pl Linux szerver Windows oprendszer. Még annyi előnye van, hogy kimentheted az image-t, aztán megoszthatod a többi fejlesztővel, ha csapatban nyomulsz. Így szerver beállítások beli különbség, meg ilyesmi nem okoz majd konfliktusokat, feltéve ha fel tudod szórni a szerverre ugyanazt az imaget.
Van még a vagrant, elvileg azzal leírhatod, hogy az aktuális imaget hogyan hoztad létre, szóval hogy hogyan került ebbe az állapotba a virtuális géped vagy a docker container-ed. Elvileg mindkettőnél lehet menteni az image-t is futás közben, gyakorlatilag nem tudom, sosem használtam egyiket sem. A vagrant azért lehet jó, mert belenyúlhatsz a szoftvercsomagba és a beállításokba anélkül, hogy mindent kézzel kellene nulláról újratelepítened. Valami olyasmi ránézésre, mint egy verzió kezelő a futási környezetre.
Nekem ránézésre egyikre sincs most szükségem, de csapatban mindenképp hasznosnak tűnnek, ugyanígy asztalihoz is, ha több oprendszert akarsz támogatni.
-
#5584
inf3rno
nagyúr
PumpkinSeed
#5578
inf3rno
nagyúr
válasz
PumpkinSeed
#5578
üzenetére
Találtam bug reportot, +1-ezzél rá, hátha hamarabb javíták. [link] Windows-on még csak pár hónapos a docker valszeg amiatt bugzik még. Fél év múlva már biztosan jobb lesz. Majd kipróbálom én is, hátha többre jutok, bár fogalmam sincs, hogy mire tudnám használni.
-
#5582
inf3rno
nagyúr
PumpkinSeed
#5578
inf3rno
nagyúr
válasz
PumpkinSeed
#5578
üzenetére
Melyik oprendszeren próbáltad?
-
inf3rno
nagyúr
Ja, mindenki azt használ.
Na összeszórtam babel-el is, nehéz szülés volt, mármint a nodejs jasmine teszt vele. [link] A végén úgy döntöttem, hogy becsomagolom browserify-al az egészet egy pack-ba, aztán úgy tesztelem. Próbáltam jest-el is, annak elvileg van preprocessor-a, ami babel-el átalakítja, de bugos. Facebook fejlesztők kontár munkája...
Úh. azzal nem jött össze a dolog. Most megy, de kellene még bele egy source map, amit nem tudom, hogy fel tudok e építeni browserify+babelify+uglify kimenetéből. Talán ha minden összejön, akkor igen. A következő probléma meg az lesz, hogy hogyan alakítom át a jasmine hibaüzeneteit a bundle-ről valami épkézláb dologgá a sourcemap segítségével. Meglájuk. Még úgysem használtam sosem ilyesmit. -
inf3rno
nagyúr
C#-ot valszeg nem fogom, mert búcsút mondok a windows-nak. A java szimpi, de csak fél évet foglalkoztam vele, akkor se túl komolyan. Jobb szeretem a könnyű súlyú dolgokat. Majd talán kisebb asztali alkalmazásokat rakok össze java-ban. De elvileg már node-al is lehet ilyesmit. Az android még ami izgat.
-
inf3rno
nagyúr
Persze egy ideje ismerkedek vele, tisztább, szárazabb érzés a PHP után. PHP kb olyan, mintha a fél karom hiányozna, mert a webszerver kezeli a thread-eket, meg csak szinkron kódot lehet írni vele. (Tudom, hogy van appszerver, meg nagyon próbálják pusholni páran az aszinkron PHP-t, de rajtuk kívül senki nem veszi komolyan.)
Azért a nodejs is gyerek még, nagyon kell neki, hogy stabil támogatás legyen az ES7 async function-ön. Így future-ökkel el lehet bohóckodni, de nem az igazi. Most próbálok egy object stream-hez hasonló belső üzenetküldőt csinálni aszinkron kódoláshoz. Meglátjuk hova jutok vele. Igazából már 1 éve elkezdtem hobbiból, aztán azóta már egyszer újraírtam, és most fogom másodszor is. Tisztul a dolog. Nem tudom mások hogy írnak keretrendszereket, de nekem mindig kell 2-3-4 újraírós ciklus, amitől egyre szebb meg egyszerűbb lesz a kód. Úgy néztem azért másoknál is jellemző, hogy teljesen újraírják őket, pl ext4 vagy nanomsg (ami zeromq2), symfony2, és így tovább. Nagyon ritka, hogy elsőre megtalálja a legjobb megoldást az ember.
-
#5569
inf3rno
nagyúr
PumpkinSeed
#5566
inf3rno
nagyúr
válasz
PumpkinSeed
#5566
üzenetére
Ha a VM nem játszik, akkor próbáld meg a docker-t. Az kevesebbet eszik, és ugyanazt tudja. (Még nem foglalkoztam vele, de mások nagyon ajánlják.)
Nekem a projekt mappa külön HDD-n van, az összes projektnek abban van a kódja egy-egy mappában. A felosztásnál nekem most bejön a forrás az src-be a build meg a dist-be, a build task-ek mennek a tasks-be, a tesztek meg a spec-be. A runnerek a project root-ban vannak. Nagyjából ennyi a történet. Ha csapat van, akkor még bejön a képbe a CI szerver, a kódokat ott kell integrálni, aztán tesztelni és release-elni. Ha nincs csapat, akkor én nem szoktam ilyesmivel foglalkozni, letesztelem itthon, aztán kitolom a release script-el. Egyedül a rollback hiánya, ami aggasztó ilyenkor, de magabiztos vagyok.
Nem jellemző, hogy oprendszerbeli eltérések miatt bármi történne. Legalábbis webes fejlesztésben nagyon ritkán találkozok ilyesmivel legtöbbször mod rewrite meg env vars témában, asztalra meg mobilra nem fejlesztek (még), azoknál gondolom nagyon más a helyzet. Nálam kb ennyi a történet.Én nem tudnám megszokni, hogy több oprendszert használok fejlesztésre. Most váltok majd linux-ra win7-ről, teszteltem egy csomót. De hogy ide-oda váltsak az oprendszerek között meg rebootoljak, amikor egy projekthez akarok nyúlni, az kizárt. Akkor már jobb a VM vagy a docker.
-
inf3rno
nagyúr
Magával a nyelvvel csak annyi, hogy xarból nem lehet várat építeni. A PHP4 kb olyan volt, mint a js-ben a típusellenőrzés. Azóta rátákoltak a tetejére egy oop réteget, kb. ennyi történt. Ugyanúgy szinkron, nem lehet aszinkron kódot írni benne, sem többszálút. Általában aztán az van, hogy az ügyfél kiválasztja magának a legolcsóbb tárhelyet, megveszi, kattintgat párat joomlában, vagy hasonló CMS-ben, aztán rájön, hogy ehhez nem ért, és akkor fejlesszek neki PHP-ben LAMP-ra valamit, feléből mennyit engedek alapon. A másik lehetőség ugyanez, csak az első versenyző spagetti kódban már félig összegányolta mielőtt belezavarodott a saját kódjába, és feladta, és hát nekem már csak "alig valamit" kell lekódolni. Meguntam ezt az életérzést. Úgy döntöttem, hogy ez így nem vezet sehova. Inkább elméletben képzem magam addig könyvekből, amennyi nekem kell, DDD, BDD, REST, SOLID, meg hasonló betűszavak terén, aztán ezentúl csak saját projekteket csinálok, pénzt meg másból keresek. Ennyi a bajom az egésszel.
Itt a karmás [link]. Egyelőre nem találtam még olyat, amivel jasmine teszteket össze tudok kombinálni babel-el, más dolgom volt. A Jest elvileg jó rá, gyakorlatilag jobb szeretném megoldani először anélkül.
-
inf3rno
nagyúr
Egy jó ideje már jasmine-el tesztelek TDD-vel, újabban meg cucumber-el BDD-vel. Szerintem jasmine teljesen alkalmas munkára. Mocha-t is megpróbáltam annak idején, de nem sikerült elindítani sem...
Most nem melózok egy ideje, biomérnök állást keresek, meguntam a programozást, mármint azt a részét, hogy tucat webshopokat kell php-ben programozni. Ki nem állhatom azt a nyelvet, elég volt belőle pár év.Jövőre ha lesz egy kis szabadidőm labor mellett, akkor összeszórok egy cucumber+jasmine kombinációt, mert a mostani cucumber elég fapados, és csak annyira lenne szükség, hogy jasmine fölé építsünk egy speckó test loadert, ami a gherkin syntax-os scenario-kat lefordítja jasmine-re. Ezt azért pár hét alatt össze lehet hozni sztem. Elvileg talán még gherkin parser is van készen, csak össze kell tákolni a jasmine-el.
Közben sikerült összekombinálni jasmine+browserify+karma+gulp-ot. Még dolgozok rajta pár órát, aztán felteszek egy project templatet github-ra. Jó lenne még ilyen finomságokat, hogy sourcemap meg coverage meg ilyesmik is beletenni. Talán majd később. Ha fent van, akkor hozzácsapok egy babelify-t is külön branch-en aztán belinkelem.
-
inf3rno
nagyúr
Nem sikerül összehozni, bugzik karma, úh. nem tudom kiküldeni automatikus tesztre böngészőbe a bundle-t. Ha sikerül összehozni egy fejlesztői környezetet karmával, jasmine-el és browserify-al és sourcemap-el, akkor tudok majd foglalkozni vele. Nem ma lesz, az már biztos.
-
inf3rno
nagyúr
Egyelőre eddig jutottam vele:
var browserify = require("browserify"),
fs = require("fs");
module.exports = function () {
return browserify()
.require("./dist/nodelist.latest.node.min", {expose: "nodelist"})
.bundle()
.pipe(fs.createWriteStream("dist/nodelist.latest.bundle.js"));
};Annyi jött le, hogy a bundle() egy readable stream-et ad, amit aztán át lehet pipe-olni fájl írós stream-be. Ebben az esetben csak egy modult csomagoltam bele, és publikussá tettem, mert böngészős jasmine tesztekből akarom elérni. Ha magamnak fejlesztettem volna, akkor karma-browserify-t rakok alá, és nem mentem ki külön fájlba, de az már más kérdés.
A te régi kódod elvileg nagyjából jó, csak a glob-ot kéne hozzácsapni. A vinyl source egy douplex stream, ami hozzácsapja a fájlnevet, szóval csak simán át kell küldeni rajta, aztán a dest-hez adni. Azt nem néztem még, hogy pontosan a fájlnév hozzáadása hogyan történik, gondolom van valami konvenciójuk rá, lényegtelen.
gulp.task('js', function () {
return browserify({
entries: glob('./resources/assets/js/*.js'),
debug: true,
transform: [babelify]
})
.bundle()
.pipe(source('bundle.js'))
.pipe(gulp.dest('./public/assets/js'));
});A recipes-ben is amúgy valami ilyesmit használnak. [link]
Egyelőre még nem volt időm megnézni, mindjárt kipróbálom. Annyira nem vagyok elszállva babel-től, mint sokan. Valszeg nem fogom használni, inkább megvárom, amíg stabil lesz az async function. Azt írják, hogy draft jelenleg: [link], ami nekem nem elég.
Amúgy semmi gond nincs gulp-browserify-al, amíg kompatibilis gulp-al. Kösd meg, hogy 3.x-es gulp legyen a lib-ed függősége, mert azt írják, csak azzal kompatibilis. Valszeg a 4.0-s gulp-al el fog törni.
-
inf3rno
nagyúr
Közben találtam egy életképes workaround-ot karmához a TDD-vel való csomagoló írásra. Mivel az autoWatch be van lőve, ezért meg tudom azt csinálni, hogy elindítom webstorm terminal-ból a karma-t a config fájllal, aztán otthagyom. És ha közben módosítom a fájlokat, amit a karma feltölt magának, akkor automatikusan lefut a teszt utána minden alkalommal ugyanazt a böngésző ablakot használva. Ehhez nem is igazán kell kódot módosítani, mert most is két külön npm script indítja a csomagolást és a tesztelést. Egyszerűen elég csak a csomagolós scriptet használni a fejlesztés során és hagyni az autoWatch-ot, hogy működjön, a travisben meg majd mindkét scriptet futtatom egymás után, ha erre lehetőség van. Arra gondoltam, hogy a travis-nél még beteszek majd egy env var-os állítót, ami hozzáad több böngészőt is a karma config-hoz meg többféle csomagot is tesztel. Pl a commonjs-es csomagot browserify-al, a sima böngészős csomagot meg anélkül, és így tovább. 10 féle tesztet össze lehet így szórni.
Arról még mindig nem találtam info-t, hogyha a window-hoz nyúlunk egy fájlban, akkor arra milyen szabályok vonatkoznak commonjs-es csomagolásnál meg browserify-os visszaalakításnál. Abból indulok ki, hogy semmi extra nincs vele, ugyanúgy használhat window-ot továbbra is. Egyedül arra kell figyelni, hogy amit fel akarunk használni a kódunkban, arra legyen egy module.exports is a végén. A window-ból konkrétan olyan dolgokat ránt be, amik elsősorban böngészős dom-ra jellemzőek. Szóval nem ír, inkább importál dolgokat. Ezért gondolom úgy, hogy nagy kárt nem tehet, ha így hagyom. Nyilván a nodejs-es dom modulokkal egyelőre nem lesz kompatibilis, de majd a későbbiekben azt is hozzáadom. Elég lépésről lépésre haladni...
-
inf3rno
nagyúr
Azt hiszem egyelőre most én is hagyom. Nem én csinálom a projektet, csak a csomagolás részébe segítek bele, aztán gondoltam legalább az legyen TDD alapon. Legalább egy pár szimpla jasmine tesztet írok majd arra, hogy megy e a böngészőben a lib vagy nem. A jquery-t akarja kiváltani vele a srác. [link]
Ha valakit érdekel, akkor karma-ban singeRun-al így oldható meg rendesen:
var karma = require("karma");
module.exports = function (done) {
var server = new karma.Server({
configFile: "../../../karma.conf.js",
singleRun: true
}, function (exitCode) {
done();
});
server.start();
};Az előző kód valamiért singleRun: true esetében ha hibás volt a teszt, akkor elszállt valamilyen gulp hibával. Nem értek a lelki világához, debugra meg most nem igazán van időm. Ennél is fontos, hogy a karma config fájlban __dirname-t használjunk, különben rossz helyet állít be basePath-nak. Ne kérdezzétek miért, valszeg ez is egy bug lehet. Már reportoltam.
-
inf3rno
nagyúr
Azt nézem hatalmas különbség nincsen, csak annyi, hogy streamelhetővé teszi browserify-t. Elméletileg enélkül is működnie kellett volna sima callback-el. Így azért szerintem sokkal szebb, hogy tudja a gulp src-t használni, és nem kell glob-ot meg ilyesmiket beletákolni a kódba. Majd ha kipróbálom babel-t, akkor visszatérek ehhez. A webpack-re azt mondják, hogy babel-el gyorsabban csomagol, meg hogy kisebb a minified fájlméret is. Azért nem olyan egyszerű belőni, mint a browserify-t.
Karmával van tapasztalatod? Azzal küzdök, hogy gulp task-el szervert indítsak, ami nem záródik be a gulp task végén sem. Gondolom child process-be kellene tenni valahogy, és belőni daemon-nak a child process-t. Egyelőre idáig jutottam:
var karma = require("karma"),
gutil = require("gutil");
module.exports = function (done) {
var server = new karma.Server({
configFile: "../../../karma.conf.js"
});
server.on("browser_error", function (browser, err) {
gutil.log("Karma Run Failed: " + err.message);
throw err;
});
server.on("run_complete", function (browsers, results) {
gutil.log("Karma Run Complete: " + results.failed ? "Some of the Tests Failed" : "No Failures");
done();
});
server.start();
};module.exports = function (config) {
config.set({
basePath: __dirname,
frameworks: ['jasmine'],
files: [
{pattern: 'src/nodelist.js', included: true},
{pattern: 'tests/*.js', included: true}
],
exclude: [],
reporters: ['progress'],
port: 9876,
colors: true,
logLevel: config.LOG_INFO,
autoWatch: true,
browsers: ['Firefox'],
captureTimeout: 6000,
singleRun: false
});
};Az a kínja most, hogy a teszt futása közben megakad az egész a singleRun: false miatt. Gondolom ezt a részt valahogy ki kellene szervezni child process-be, aztán megpingelni a szervert, hogy fel van e lőve. Ha igen, akkor meg hagyni, hadd dolgozzon. A gond csak az, hogy elvileg ezt a karma magától megteszi. Szóval nem tudom, hogy melyik részt lenne érdemes child process-be tenni, és hogyan kommunikálni vele. Láttam, hogy van olyan, hogy karma client, lehet, hogy a szervert miután a child process-be tettem csinálni kell egy client-et, ami majd kommunikál vele. Gondolom a fájl frissítéseket az autoWatch automatikusan megcsinálja, szóval azzal a részével nem lenne gond. Hát egyelőre zavaros, dokumentáció meg általában nem nagyon van ilyen mélyebb dolgokról. Majd feltúrom a kódot, aztán lesz valami.
-
inf3rno
nagyúr
Közben kiderült, hogy a sorrend stimmel. A gond nem ezzel van, hanem nagy valószínűséggel az entries nem fogad glob patternt, csak útvonalakat egy tömbben. Szóval ha egy glob kimenetet rátennél, akkor valszeg működne. Legalábbis a példakódok alapján, amiket eddig láttam. [link]
-
inf3rno
nagyúr
Hmm érdekes, itt is úgy használják, ahogy te [link]. Majd ránézek valamikor, ha kiokodtam egy kicsit gulp-al, de gyanítom, hogy addigra megoldod. Ha már szóba került, nincs valami info-tok arról, hogy browserify-al hogyan tudnék kompatibilissé tenni egy totál böngészős kódot? Ilyen window.Symbol meg window.NodeList meg ilyeneket használ. Browserify-nak úgy tudom commonjs modul kell. Jó ugyanígy window-ot használva és elég csak a végén egy module.exports-ot betenni?
-
inf3rno
nagyúr
Hát ilyenkor első körben érdemes lenne konzolba kiíratni, hogy mégis mi a browserify({ entries: './resources/assets/js/*.js', debug: true }).transform értéke, ha nem függvény. Gondolom undefined. Ránézésre én azt mondanám, hogy először kellene a babel kódot átalakítani normál js-re, és csak utána átküldeni browserify-on, mert úgy sejtem, hogy a browserify nem tudja feldolgozni a babel kódját. A kód alapján pont fordítva ülsz a lovon. Persze lehet, hogy én tévedek. Browserify-t ma akarom fellőni először gulp-al, karmával meg nightwatch-al egy böngészős projekt tesztelésére. Az utóbbi kettő már ment, de elfelejtettem mióta utoljára használtam őket.
-
-
inf3rno
nagyúr
Babel-el kapcsolatban tudsz némi információval szolgálni? Leginkább az érdekelne, hogy async function és Object.observe mennyire működik vele msie alatt (gondolom babelify + browserify amit használni kellene hozzá). Ha ott megy, akkor mindenhol. Ha meg ennyire széles a support, akkor nem szórakozok ES5-el, hanem inkább áttérek rá én is.
-
inf3rno
nagyúr
válasz
zsolti_20
#5530
üzenetére
Persze, oninput például ilyen. Régi msie-ben onpropertychange-el lehetett ugyanezt elérni, nem tudom, hogy a mai msie támogatja e már az oninputot. Lehet még huncutkodni Object.observe-el meg setterrel, de az első azt hiszem még nem támogatott, a második meg nem hiszem, hogy DOM node-ra támogatott, vagy hogy azon keresztül állítaná e be az értéket. Ami még esetleg szóba jöhet, ha nem input-ról lenne szó, hogy setInterval-al nézed az értékét, hogy változott e, de az már tényleg fapados megoldás.
-
inf3rno
nagyúr
Van valami ötletetek, hogy hogyan tudnék svg megjelenítés sebességén javítani? Firefox, MSIE rohadt lassú, eszi a processzort és szaggat közben a scroll. Egyedül az opera, ami normálisan megjeleníti gond nélkül. (yEd-ből exportáltam egy gráfot, és azt szeretném betenni egy weboldalra. Mindenhol azt olvasom, hogy az SVG animációk okoznak magas CPU-t, hát nálam anélkül is beszaggat. Lehet inkább d3-al kellene kísérleteznem, csak az annyira gagyi hierarchical layout-nál, legalábbis még nem láttam olyan példát, ami a grouping-ot is megoldta volna áttekinthető módon, ahogy a yEd teszi.)
-
inf3rno
nagyúr
Még régi msie-kben volt ez gond, amikor az enumerable nem volt implementálva és állandóan betette a konstruktort meg az Object.prototype-ban lévő dolgokat a for-in-be. Ma már van ES5 support, és hasOwnProperty nélkül is rendesen elmegy a for-in. Olyasmivel próbálkoztam, hogy enumerable: false-ra állítom a metódusokat, hogy néhány örökölt property-t be lehessen járni for-in-el. Ezeket kiszűrné a hasOwnProperty. Sajnos nem jött be a dolog a már említett böngészők közti eltérések miatt.
Igen, tisztában vagyok vele, hogy vannak erre callback-es megoldások, de én jobban szeretem a hagyományos ciklusokat, leginkább azért, mert sokszor elfelejtem kitenni a bind-ot a végére a callback-nek.
-
inf3rno
nagyúr
Ha van szabadidőd, akkor a helyedben beleolvasnék a "ddd strategic design" részébe egy-két cikknek, könyvnek, ilyesmi, hátha találsz valamit, amit erre az esetre lehet alkalmazni. Rosszul megírt projekteken is lehet vele javítani valamennyit. Azért csodát ez sem tud tenni az eddigiek alapján.
A tesztek nélküli refaktorálás meg nem egy ajánlott dolog. Érdemes lenne legalább 1-2 e2e tesztet beletenni így utólag a main feature-ök tesztelésére, hogy nagyon fontos dolgok ne törjenek el, ha átírtok valamit. Ez azok alapján, amit elmondtál, bármikor megtörténhet, amikor hozzányúltok a kódhoz.
Sajna a legacy-val ez van általában. Egy idő után túl nagy erőfeszítés megjavítani, az ember legszívesebben újraírná az egészet, de azért meg nem fizet senki, mert hát a mostani a rendszer is "jól" működik. A refaktorálásért sem fizetnek, hacsak nem sikerül elmagyarázni nekik, hogy minél többször nyúltok hozzá a kódhoz ilyen formában, annál valószínűbb, hogy széthullik az egész.
Úgy emlékszem, hogy for-in-el próbálkoztam a bejárással, és az Object.defineProperty-nél az enumerable: false eltérően öröklődik az egyes böngészőkben. Valahol nem kerül be bejárásnál a listába az öröklött tulajdonság, valahol meg bekerül. Azt hiszem ugyanígy hibák voltak a setter, getter, congfigurable terén is, de ezt nem mondom biztosra. Küldtem mindegyik major böngészős cégnek bug report-ot, hogy jó lenne közös nevezőre jutni ezzel kapcsolatban, de egyik sem reagált, úgyhogy én inkább nem használom többet azt a függvényt meg a for-in-t bejárásra (kivéve config objecteknél, meg 1-2 helyen). Sugar syntax-hoz kellett volna csak, megoldottam másképp, úgyhogy nem lényeges.
-
inf3rno
nagyúr
A BDD-t és a DDD-t próbáltátok már, vagy ahhoz meg még túl kicsi a projekt?
Én most olvasom a Vaugh Vernon könyvet DDD-vel kapcsolatban. Elég jól leírja, hogy hogyan lehet szétszedni kezelhetőbb méretű részekre óriás alkalmazásokat. Szerintem kliens oldalra is használható az elv, ha már akkora lenne a kód.
A BDD-ehhez többé-kevésbé szorosan kapcsolódik. Nálam kb annyiról szól, hogy cucumber-ben megírod a use case-eket a domain model nyelvén, utána ezeket lefordítod tesztekre step definition-ökkel. Aztán teszteled vele az alkalmazást. Lehet csak a domain model-t is tesztelni, amiben a business logic van, de akár e2e teszteket is lehet írni, és a kliens oldalról megközelítve tesztelni az egész alkalmazást (ez jóval lassabb). Elég széles a tárház, hogy mit tudsz tesztelni, és nagyon rugalmas, mert a step definition-ök szabadon cserélhetőek úgy, hogy közben a use case-ek ugyanazok maradnak felettük. Ha változik a megrendelői igény a logikát tekintve, akkor változik a use case is, ellenkező esetben viszont csak a step definition-höz kell hozzányúlni, ha éppen gombra kell kattintani link helyett vagy ilyesmi egy űrlap küldéshez. Egyelőre ezzel is csak kísérletezek, de egyre inkább úgy tűnik, hogy be tudom venni hagyományos TDD helyett a napi rutinba.
A kliens oldalon örök szopás, hogy 1000 féle környezetet kell megtámogatni. Nem új dolog. Én futottam már bele mostanában natív js bug-ba is. Nagyon kellemetlen, mert órákon át lehet keresni a kódodban, hogy hol a hiba, miközben nem ott van, hanem a js motorban... Ha nem TDD-vel írtam volna a kódot, akkor elkapálhattam volna magam, mert debug-nál még nehezebb egy ilyet leszűkíteni pár sor kódra. TDD-nél azért képben vagy, hogy éppen mire írtad 1 perce a tesztet.
Async-hez te milyen lib-eket használsz?
-
inf3rno
nagyúr
"inf3rno: typescript, dart, coffee, elm.. egyeni preferencia kerdese, szerintem ezek csak akkor hasznosak ha Java-n nevelkedett embernek kell JS kodot irnia. <tapasztalat>"
Személy szerint én annak idején js-el kezdtem, mint script kiddie, és nekem tetszik a TypeScript. Java-t tanultam egy keveset, de inkább az erős oo alap, ami miatt bejön, nem pedig a Java tudás miatt. Te funkcionálisan programozol js-ben, legalábbis a kódjaid alapján, ahhoz gondolom megfelel az a validálási forma, amit használsz. Én inkább az oo fele hajlok, ahhoz meg más eszközök a jobbak, pl TDD, vagy újabban BDD az alap, meg hogy minden sor kód tesztelve van. Ennél a megközelítésnél nekem kifejezetten zavaró, ha típusellenőrzésre kell teszt kódot fecsérelni. Nagyjából ennyi a különbség.
-
inf3rno
nagyúr
"This may not make sense at first but when you start dealing with multiple frames or windows in your script and pass objects from one context to another via functions, this will be a valid and strong issue."
Nekem továbbra sincs értelme. Mármint persze elfogadom, hogy nem működik, mert a böngészőket így tákolták össze, de ez sajna jellemző a kliens oldali fejlesztésre, hogy nekünk kell alkalmazkodni mások hülyeségéhez. Eléggé conformist viszonyban vagyunk a böngészőgyártókkal, nem customer-supplier-ben, hogy DDD-s szavakat puffogtassak. Ez már a kezdetek kezdete óta így van sajnos. Nem véletlenül utáltam meg a kliens oldali fejlesztést, és mentem át inkább szerverre.
-
inf3rno
nagyúr
1.
Hja, meglepődtem. Leginkább a null-on... Ezt a validációs részét a js-nek már 10 éve is újra kellett volna írni szerintem. Az egész egy jó nagy katyvasz. Elég hasonló a PHP-hez ilyen téren.2.
Erre mondtam, hogyha annyira a típus validálással akarsz molyolni, akkor érdemesebb TypeScriptet használni.Én személy szerint így oldanám meg a dolgot sima js-el:
function doStuff (inputArray) {
if (!(inputArray instanceof Array))
throw new TypeError("Array required.");
return inputArray.map(makeChange);
}aszinkron esetben meg
function doStuff (done, inputArray) {
if (!(inputArray instanceof Array)) {
done(new TypeError("Array required."));
return;
}
done(null, inputArray.map(makeChange));
}Primitíveknél is ugyanúgy jó a typescript, vagy ha nem szeretnél compile-t, akkor valóban írhatsz olyat, hogy
if (utils.typeOf(value, String))
és hasonlókat.
Szvsz. nem muszáj minden esetben ennyire szigorúan típusellenőrizni. Attól függ, hogy mire fejleszted a kódot. Ha valami kisebb projekthez kell gyorsan összeszórni olyasmit, amit ránézésre átlátsz, akkor felesleges erre időt pazarolni.
Leginkább az a hátránya ennek a nem beépített típusellenőrzésnek, hogy TDD-vel a teszt kód nagy része erre megy el, ahelyett, hogy a tényleges funkciókat tesztelné az ember.
-
inf3rno
nagyúr
Szvsz. nem bad practice. Nem minden esetben kell annyira szigorúan venni a típusellenőrzést. Főleg nem ha általában kivételeket dobunk hibánál, nem null-al és hasonlókkal térünk vissza. Ha mégis kell komolyabb típusellenőrzés, akkor ott a typescript, és megintcsak használható a !x vagy !!x, stb...
-
inf3rno
nagyúr
Nem mondanám, hogy nem követem a fejleményeket, legalábbis es-el kapcsolatban tisztában vagyok az újdonságokkal. ES7-nél az Object.observe a legfontosabb dolog, de ahogy nézem egyelőre csak a chrome alapú dolgok támogatják. Azon kívül még érdekes az async functions, amit böngészők még nem támogatnak, de babel és traceur igen. Próbálgasd azt, kíváncsi vagyok, hogy mennyire fekszik majd neked. Ajax-al kapcsolatban úgyis async dolgokról kérdeztél. Elvileg ez az es7-es feature a megoldás a velük kapcsolatos minden problémára, ha nagyon optimisták vagyunk...
-
inf3rno
nagyúr
Ennyire nem folytam bele babel-be. Nekem van saját class lib-em úh. nem adna semmi extrát, amíg a böngészők nem támogatják es6-ot, addig meg nem foglalkozok vele. Nem szeretnék compilert, ha nem muszáj, megszoktam már így. Később lehet, hogy változik, ha rászokok a browserify-ra böngészőnél meg arra is, hogy sűrűbben használjam a gulp-ot.
-
inf3rno
nagyúr
Hát sok sikert, van amúgy kismillió ilyen nyelv, ami js-re fordul, itt [link] a felső sor nagyjából lefedi, hogy mivel érdemes foglalkozni. Persze még ezen kívül is van egy csomó, mint pl coffee, de attól meg már falra mászok. Én a normál js-t szeretem, az ilyen compiler-ekkel nem vagyok kibékülve. Azért lehet, hogy később én is csinálok egy saját nyelvet compiler-el aszinkron dolgok kezelésére, mert megvan róla a saját elképzelésem.
-
-
inf3rno
nagyúr
A gond itt, hogy az ajax aszinkron, te meg szinkron gondolkodsz. Az ajax-nál elmegy a kérés szerver felé, és egy eseményt vált ki, ha megjött a válasz, hasonlóan, mint pl onclick-nél is csak akkor fut az eseménykezelő, ha kattintás történt. Szóval miközben megy az ajax, a szinkron kód ugyanúgy dolgozik tovább, nem vár arra, hogy megjöjjön a válasz, a választ lekezelni az eseménykezelő dolga. Két dolgot tehetsz. Vagy alkalmazkodsz és aszinkron kódot írsz callback-el, vagy beállítod, hogy szinkron legyen az ajax kérés. Általában inkább az előbbit szokták javasolni, és a szinkron ajax-ot bad practice-nek tekintik, de te döntöd el, hogy neked mi a jó.
-
inf3rno
nagyúr
Kinek a pap, kinek a papné. Én azért gondoltam d3-ra, mert az a bevett adat ábrázoló lib, aztán hátha megtetszik neki valamelyik másik ábrázolási mód is. Pl én egy hőmérő adatot, vagy ilyesmit inkább grafikonon látnék szívesen, ahol horizontálisan az idő van. Azt, hogy mire kell, meg ő tudja.
Ezért írtam meg inkább kézzel.
Hát az általános keretrendszerek legtöbbször csak arra jók, hogy gyorsan összeszórj valamit. Ha komolyabb igények vannak, akkor kénytelen vagy egyedi kódot írni hozzá. Sebességben sincsenek ezek a libek ott, mint a kézzel összerakott, bár azért már fordítanak figyelmet az optimalizálásra is.
-
inf3rno
nagyúr
A d3 csak arra kell, hogy data binding legyen az SVG-vel, és így tudjon realtime frissíteni pl websocket-en ékező szenzor adatok alapján. Ha ez nem szempont, és mondjuk egy szerver oldali script állítja elő az SVG-t, akkor valóban nincs rá szükség (de kétlem, hogy nodejs-ről lenne szó). Persze lehet manuálisan is data binding-ot csinálni, ha neked ahhoz van kedved, nem fog vissza senki.
+1, maga a business logic egy szimpla egyenes arányosság, nem kihívás, ahogy a többi része sem.
@Carasc0
Szó sincs több napról, néhány óra az egész. Amit linkeltem, abban meg csak ugyanúgy át kell állítani, mint Karmájéban, hogy mettől meddig veszed a skálát.
-
inf3rno
nagyúr
Úgy néz ki megvan a vmware-es bluetooth smart hiba oka: az android 4.3-tól van csak bluetooth smart támogatás [link]. Sajnos eddig nem sikerült túljutni a boot képernyőn android-x86-4.4-nél, azt mondják, hogy valami kompatibilitási problémája van a vmware-el, de azért majd még próbálkozom, hallottam olyanról, akinek összejött. Bocs a floodért!
-
inf3rno
nagyúr
válasz
Carasc0
#5375
üzenetére
Nézz körül d3.js és svg témakörben. Vannak hasonlók: [link]. Egyébként a progress bar az teljesen más, mint amit te akarsz. Nulláról max 1 hét alatt összehozod, ha nagyon lassan tanulsz. Ingyen általában csak akkor dolgozunk, ha saját magunknak csinálunk valamit (én legalábbis így vagyok vele).
-
inf3rno
nagyúr
Egyébként most nem USB perifériáról van szó, hanem integrált bluetooth-ról. A régi verziós bt megy is, csak a 4.0 nem, legalábbis nem ismeri fel az eszközt. Windows-ban már sikerült párosítani, de az is csak sokadikra ment, úgyhogy nem tudom, hogy a kapcsolódással van e a gond, vagy a bt smart nem működik. Valószínűbb, hogy inkább az utóbbi, és vagy a vmware vagy az android-x86 nem támogatja a bt smart-ot. Próbáltam release logokban utánakeresni, de google semmit nem dobott róla, a vmware fórum regisztrációnál meg csak a személyi számomat nem kérdezik meg...
-
inf3rno
nagyúr
Semmi. Az a problémám, hogy windows-ra nincs megírva a program, amit használni akarok, csak androidra. Ha sikerülne is GATT-ról adatot nyerni a BT smart eszközről, akkor is vannak olyan funkciók, amiket valszeg nem tudnék használni (pl beállítások), mert nem tudom, hogy hogyan implementáljam őket, úgyhogy egyszerűbb lett volna felszórni a laptopomra egy emulált androidot, amin telepíthetem a szoftvert, aztán megnézhetem, hogy tényleg jól működik e a kütyü.
Megpróbáltam virtualbox-al is, azzal a telepítő képernyőig jutottam, ott viszont úgy tűnt, hogy a virtualbox nem érzékeli a billentyűzetet, úgyhogy nem tudtam tovább lépni. Próbáltam beállítani, de nem kapta el a keystroke-okat a beállításnál sem. Utána megpróbáltam újraindítani, akkor meg valami értelmezhetetlen hibaüzenetet szórt. Ezek után tényleg jobb a vmware. Az is bugos, de legalább nem ennyire durván...
Majd kölcsönkérek egy bt smart-os mobilt, aztán kipróbálom azzal, addig meg megnézem, hogy ez a WinJs GATT hogy szuperál, ha már így belejöttem.
-
inf3rno
nagyúr
Közben felszórtam a laptopomra vmware-t player-t. Úgy gondoltam, hogy a rövidebb utat választom, és felteszek rá egy androidot, ahhoz vannak programok, és úgy nem kell GATT-al bohóckodni. Feltettem egy android-x86-4.4-rc2-t elsőnek, hát befagyott az induló képernyőnél, azt mondják ez ismert hiba 4.2 óta. Feltettem így egy 4.0-t, azon viszont nincs net, és a bluetooth-nál sem látom a bt smart eszközömet, csak a régi bt-os mobilomat. Biztos, hogy lehetséges vmware-el bluetooth smart-ot megosztani az emulált rendszerrel?
-
inf3rno
nagyúr
"The company I work for make test equipment and one of my co-workers has to test the USB drivers we supply for this equipment under a range of operating systems; he says VirtualBox is useless for this but he can use VMware." - jul 14 [link]
Ezek szerint a WMware jobban passzol ehhez az USB adapteres Bluetooth Smart-os fejlesztéshez, mint a VirtualBox.
-
inf3rno
nagyúr
Bármi ötlet, hogy win7-ről hogyan tudom megoldani a winjs befordítást és tesztelést?
Gondolom az integrációs tesztekhez kell majd virtualbox meg emulált 8.1, jól sejtem? Egyáltalán bluetooth kapcsolatot hogyan tudnék tesztelni egy olyan gépen, amin nincs is? Lehet, hogy egyszerűbb lenne, ha a win8 adaptereket a tabletemen tesztelném(azon 8.1 van), a kódot meg git push-al frissíteném rajta. A maradék integrációs teszteknél meg kimockolnám a win8 specifikus adaptereket. Életszerű ez az elgondolás?
-
#5356
inf3rno
nagyúr
PumpkinSeed
#5355
inf3rno
nagyúr
válasz
PumpkinSeed
#5355
üzenetére
Tudom, hogy van, de ha folyamatosan Gb-okat ír rá a VS, mert kevés a memória, akkor elhasználódhat elég hamar (ugyanúgy, mint torrent esetében). Vannak programok, amikkel le lehet kérni, hogy mennyit ír rá, és megjósolnak egy élettartamot, de annyira nem folytam bele a témába, hogy konkrétat ajánlani tudjak.
NB-ben az autocomplete nem volt az igazi, nincs jsdoc3 support sem. Lehet, hogy azóta már tákoltak rajta, nem használtam már évek óta. Ettől függetlenül azért egész jó volt, talán a legjobb az ingyenesek közül.
-
#5353
inf3rno
nagyúr
PumpkinSeed
#5348
inf3rno
nagyúr
válasz
PumpkinSeed
#5348
üzenetére
Szerintem bővíts. min 20k egy Webstorm licensz, min 15k egy SSD, ha megenné, 4gb memóriát meg 8k-ért kapsz már jót.
-
-
-
-
inf3rno
nagyúr
Köszi! Nagyjából erre voltam kíváncsi, hogy nem reménytelen. Olvastam olyat egy fórumban, hogy valakinek összejött C#-ban ezzel a kütyüvel, úgyhogy talán nem titkosított az adatküldés. Elvileg ugyanaz az API (legalábbis ránézésre) WinJS-nél és a C#-os WinRT-nél is, úgyhogy szerintem át lehet írni sorról sorra.
-
inf3rno
nagyúr
Ez csak hobbi projekt, nem üzleti. Magamnak írok egy edzéstervezőt meg naplózót, mert már unom az Endomondo meg Strava hülyeségeit.
Hát lehetne éppen C#-al is, csak ahhoz nem értek, meg nincs kedvem megvenni a Visual Studio-t. Más alternatíva meg js-ben sajnos most nincsen. Van olyan, hogy NodeRT, ami szintén valami WinRT-s C-s dolgot fordít be dll-be, ha jól tudom, de ahhoz meg node-gyp-et vele együtt meg Visual Studio-t meg Pythont, meg minden hülyeséget fel kellene telepíteni, akkor meg már kézenfekvőbbnek tűnt, hogy WinJs-el lekódolok gyorsan egy Bluetooth-ot használni képes klienst, aztán átküldöm a nodejs szervernek vele az adatokat valamilyen protokollon.
-
inf3rno
nagyúr
WinJs-el és Bluetooth-al van valakinek tapasztalata? Szeretném lekérni az adatokat pulzusmérőről, de nem igazán tudom, hogy milyen irányba induljak. Van egy csomó hardver id, amikből néhány szabvány, mások gondolom nem, de hogy ebből én hogy kapok majd adatokat, arról lövésem sincs. Tudom rtfm, de nem lehetne egy kicsit meggyorsítani a folyamatot?
Maga az eszköz egyébként Mio Link, gondolom nem open az api-ja, de windows-hoz sajna nem szórtak össze semmit a srácok, bt4-es androidos eszközöm meg még nincsen, úgyhogy gondoltam teszek egy próbát, hátha ki tudok csikarni belőle valamit. Mérni mér, villognak a színes ledek rajta, elvileg ha jól be tudnám állítani, akkor az én edzettségi szintemnek megfelelően tolná a szivárványos színeit a pulzus zónákról, nem valami átlaghoz viszonyítva. Meg jó lenne látni a konkrét számokat is legalább egy crossfit edzésen, ha már futáshoz nem tudom a hátamra szíjazni.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Úh. azzal nem jött össze a dolog. Most megy, de kellene még bele egy source map, amit nem tudom, hogy fel tudok e építeni browserify+babelify+uglify kimenetéből. Talán ha minden összejön, akkor igen. A következő probléma meg az lesz, hogy hogyan alakítom át a jasmine hibaüzeneteit a bundle-ről valami épkézláb dologgá a sourcemap segítségével. Meglájuk. Még úgysem használtam sosem ilyesmit.
Nem jellemző, hogy oprendszerbeli eltérések miatt bármi történne. Legalábbis webes fejlesztésben nagyon ritkán találkozok ilyesmivel legtöbbször mod rewrite meg env vars témában, asztalra meg mobilra nem fejlesztek (még), azoknál gondolom nagyon más a helyzet. Nálam kb ennyi a történet.
Új hozzászólás Aktív témák
Hirdetés
- Melyik tápegységet vegyem?
- Milyen billentyűzetet vegyek?
- Lakáshitel, lakásvásárlás
- Gyúrósok ide!
- One otthoni szolgáltatások (TV, internet, telefon)
- Goddess of Victory:Nikke
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- HiFi műszaki szemmel - sztereó hangrendszerek
- Videó stream letöltése
- A fociról könnyedén, egy baráti társaságban
- További aktív témák...
- Eladó konfig! Ryzen 7 7800X3D 2TB SSD 64GB DDR5 RX9070XT 16GB!
- Új, makulátlan állapotú Samsung Galaxy Buds FE, fehér, fél év garancia
- Új, makulátlan állapotú Samsung Galaxy Watch7 44mm ezüst, 2 év garancia
- Új, makulátlan állapotú Samsung Z Fold 6 256GB Tengerészkék, független, 2 év garancia
- Használt TP-Link Deco M4 - AC1200 Router (Mesh-ként is használható)
- ÁRGARANCIA!Épített KomPhone i5 14600KF 32/64GB RAM RX 9070 16GB GAMER PC termékbeszámítással
- BESZÁMÍTÁS! 16GB (2x8) G.Skill Trident Z RGB 4266MHz DDR4 memória garanciával hibátlan működéssel
- Új és használt laptopok , üzletitől a gamerig , kedvező áron. Garanciával !
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7600X 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- HPE Apollo 4200 Gen9 2U rack szerver, 1x E5-2620v4, 64GB RAM, 24x3.5" 2U-ban! ÁFA-s számla, garancia
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest