Hirdetés

Keresés

Új hozzászólás Aktív témák

  • inf3rno
    nagyúr

    Pedig az ES6 se most kezdett terjedni :D :B

    Én végignéztem anno ES6 feature-öket, de ezt sehol nem hozták. Amúgy hasznos.

  • inf3rno
    nagyúr

    Működni működik, csak nem tudom, hogy nem csinálok-e felesleges loopokat. [link]

    Átírtam sima JS-re, nem tudom pontosan, hogy hogy működik a jsfiddle TS/Babel.

    @inf3rno: :K Optional Chaning (?.) MDN

    Köszi!

  • inf3rno
    nagyúr

    Előre is elnézést az auto-correctes felig ékezetes, felig magyar, felig angol kommentert.

    Mivel magamtol nem jöttem ra ezért osszelegoztam a megoldást, ti ezt értitek? Úgy érzem, hogy feleslegesen toltam túl a dolgot:

    const onlySelectable = allOptions
      ?.filter((e: { etype: string }) => e === 'SELECTABLE')
      .map(({ eorder, eid }) => ({ eorder, eid }));

    const filterAndAddOrderNum = (
      selectionHistory: { eid: string, selectedOption: string }[],
     onlySelectable: { eorder: number; eid: string }[]
    ) => {
      const map = new Map();
      const filteredSelectionHistory = selectionHistory?.selections?.filter(({ eid: id1 }) =>
       onlySelectable.some(({ eid: id2 }) => id1 === id2)
      );
     filteredSelectionHistory.forEach((item) => map.set(item.eid, item));
     onlySelectable.forEach((item) =>
        map.set(item.eid, { ...map.get(item.eid), ...item })
      );

      return Array.from(map.values());
    };


    Lényegében van egy forrás JSON ami mindig a friss adatokat tartalmazza, az eorder változhat es nekem az alapján kell sorrendben megjelentetni az adatokat, illetve van egy history JSON ahol eddig csak az id es a user opciója volt elmentve. A feladat, hogy miután megkaptam a forrást es a history-t szinkronizáljam azokat. Tehát a redux state-ben a history-bol kinyert eid-hoz csatoljam eorder-t, igy a frissen megjelenített adatok es a history-bol jövő adatok is szinkronban lennének, mert időközben a sorrend es a tartalom is változhat. Az esetleg (user által) ujra elküldött adatoknak is tukrozniuk kell a forrásban történt változást.

    Nem feltétlen 1 liner megoldást keresek sõt, de egy másod véleménynek örülnék, hogy lehet-e ezt egyszerűbben is.

    Ez a "selectionHistory?.selections?.filter" js szintaxis egyáltalán? Sosem láttam ilyet, de kezdem elveszíteni a fonalat a nyelvvel kapcsolatban, annyira gyorsan változik.

  • inf3rno
    nagyúr

    A datatables ingyenes, de az editor plugin nem tűnik annak. Persze lehetséges, hogy van mód az ingyenes használatra, ebben a részében nem mélyültem el.

    Ja látom, azzal rendesen lehúzzák az embert. Úgy viszont nekem már nem jó. Amúgy is a vue felé kacsintgatok már egy ideje, csak nem nagyon csináltam kliens oldali dolgokat mostanában. Ideje megtanulni.

  • inf3rno
    nagyúr

    Én ag-grid-et használtam korábban, az ingyenes része is elég sokat tud, és van integráció a három nagy framework-höz.

    Köszi!

  • 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

    Bakker..., tényleg, köszi. Sztem az életbe nem jöttem volna rá, hogy azt írtam el...

    Meg is csináltam, elvileg jól működik. Legalábbis nekem úgy tűnik 1-2 teszt után.

    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.

  • inf3rno
    nagyúr

    Kicsit hegesztettem rajta, ellenben továbbra se húzza be az adatokat a mezőkből. Kezdi már felhúzni az agyamat ez a sz@r... Amúgy jó tudni, hogy olyan formában nem is lehetett volna csinálni 2d-s tömböt ahogy akartam...
    Ha nincs .value a getElement után akkor "undefined", ha ott van akkor meg rinyál a chrome console-ja érte.
    Valaki már igazán megmondhatná, hogy a francba kell megcsinálni ezt a szutyok feladatot, mert ezekkel nemigen vagyok előrébb, amiket leírsz. Annak aki már ismeri a nyelvet annak biztos segítenek valamit a rávezetéseid, de olyannak aki kb a 0-ról indul neki annak nemsokat... :R

    kb. 2.napja csak azzal szívok, hogy a nyűves adatokat kiszedjem a megadott input mezőkből, azért ez vicc.

    ip-t írtál id helyett, azért nem működik.

  • inf3rno
    nagyúr

    "Arra, hogy a TDD/BDD többlet idővel járna mutathatnál valami bizonyítékot, mert pont az ellenkezője igaz."
    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. Mint minden általánosítás, a tiéd is itt sántít. Ha előre megvan hozzá minden infrastruktúra, valóban csakis mindenki úgy készített kódot, és valóban mindenki töltötte az idejét a minden esetre kiterjedő tesztesetek lefedésével, akkor előfordulhat, hogy nem akkora para, de van, amikor tényleg para.
    De hidd el, ezt nem bántásból vagy kötekedésből írtam le, hanem azért, mert a gyakorlat sokszor sajnos messze kell, hogy kerüljön az elméleti bullshittől, még ha az elméleti bullshitnek nyilvánvalóan lehet bőven létjogosultsága.

    "Persze ha nem veszed komolyan az egészet, vagy nem fotnos a minőség, akkor nyugodtan fejleszthetsz tesztek nélkül is."
    Hümm, tehát arra, aki valaha életében merészelt leírni TDD/BDD-elvek alkalmazása nélkül kódot céges környezetben (alap, hogy az első kör nem az éles), Te most itt ünnepélyesen kijelentetted, hogy nem veszi komolyan az egészet, meg annak nem is fontos a minőség, értem. :DDD
    Sajnos nem lettem meggyőzve - de még egyszer megemlíteném, cseppet sem becsülöm le a TDD/BDD előnyeit és szépségeit. (Egyébként meggyőzésként említettél EGY multit, ahol állítólag csak olyan kódot adnak ki a kezükből, ami ezen elvek mentén készül - egyrészt nem tudhatjuk ennek valódiságát, másrészt nem egy nagy merítési minta. De a gondolkodásmódod alapján biztos csakis ott lehet a szakma krémje, ahol ez percről-percre szem előtt van, máshol csak noobok és igénytelen k×csögök vannak. ;] :P)

    "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

    "gulp": "^3.9.0",
    "gulp-jasmine": "^2.2.0",
    "gulp-rename": "^1.2.2",
    "gulp-replace-task": "^0.11.0",
    "gulp-sourcemaps": "^1.6.0",
    "gulp-task-file-loader": "^1.0.0",
    "gulp-uglify": "^1.4.2",

    Nekem ez a bajom a gulppal meg a grunttal is, hogy ezer meg egy dependencia es kb ennyi sorbol meg ennyi kodbol ossze lehet amugy hozni a buildelest mindenfele build tool nelkul. Vagy akar egy makefile.

    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

    Fene se tudja, nekem ennyi beallitas kellett browserify-hoz, hogy menjen a babel.

    "devDependencies": {
    "babelify": "^5.0.3"
    },
    "browserify": {
    "transform": ["babelify"]
    }

    Ja es a fene se szorakozott gulppal vagy grunttal, npm o/

    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

    FYI:

    export function add() {
    var result = 0;
    for (var i = 0; i < arguments.length; ++i)
    result += arguments[i];
    return result;
    }

    Ha mar ES6, akkor miert nem hasznalod ugy, ahogy kene, vagy ahogy lehet? :) Gondolok itt..

    export default (...nums) => nums.reduce((acc, num) => acc + num, 0);

    Es ugyanez a tobbinel is.

    É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.

  • inf3rno
    nagyúr

    "Tudok olyan multiról, ahol TDD + SOLID + OOP alapvető" - melyik az? És valóban alapvető, vagy csak kifelé ezt kommunikálják?

    Nem kommunikálják kifelé, egyik haverom dolgozott náluk. Megígértem neki még régebben, hogy nevet nem mondok. Egyébként meg ez elég off topic itt.

  • inf3rno
    nagyúr

    Sikerült közben megtákolnom babel-hez a node teszteket is. [link] most már van náluk is source map, azaz hogy nem tudom, hogy sourcemap, vagy mi alapján megy, de az eredeti fájlokat írja, amikben a hiba keletkezett, a cél meg ez volt.

  • inf3rno
    nagyúr

    "Szvsz a TDD nem advanced dolog, hanem alapvető, ha fejleszteni akarsz"
    Bocs, de most már muszáj beszólnom, annyira folyamatosan erőlködsz ezzel a TDD-BDD-HDD-SSD-DDD-XXX-ASDASD-QWEQWE-BLABLA-HABLATY-vonallal (:]), hogy kezd már picit irritáló lenni. Azért komolyan kíváncsi lennék, hogy létezik olyan munkahely, ahol a fejlesztők tényleg MINDEN kódot TDD/BDD/akármi-vezérelt elven írnak? Van erre idő? (Persze elméletben ez is létezhet, ahol irreálisan nyugis a tempó.) Csak mert általában a megrendelők várnak a termékükre, a főnökök az eredményre (joggal), majd jön a következő feladat, és így tovább. Vagy ezek csak jól hangzó elvek, amiket a hobbiprojektjeidnél alkalmazol? Mert az egyébként úgy tök jó, és szép dolog, de amúgy akkor még csomó vezérelvhez tartozó mozaikszót vagy buzzwordöt be lehetne dobálni, ami a gyakorlatban azért inkább fenntartásokkal kezelendő, mert vagy működik, vagy nem, jó, ha sikerül annak mentén csinálni, de sokszor inkább az erre való törekvés jön csak össze (és már az is valami).

    É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

    Ahoi,

    AngularJS kérdés.
    Egy új alkalmazást Angularral kezdtem el, kellene bele valamilyen wyswyg editor. Ezzel valakinek tapasztalat? Láttam CK-val egészen könnyen elboldogul, illetve van a textAngular ami kimondottan Angularhoz készült és nagyon lightweight, de nincs benne képfeltöltés (bár lehet ez nem is fog kelleni, még megkérdezem az ügyféléket). Egyéb ötlet?
    Köszi!

    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

    Nekem is el kellene kezdenem Karmával teszteket írni, vagy valami hasonló, mert sajnos még ez is kimarad a repertoárból. :( Mondjuk jelenleg most inkább a stabil JS tudásra hajtok, aztán jöhetnek az advancedebb dolgok amik már a fejlesztést fogják segíteni. Túl sok már a lehetőség. :))

    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

    Persze, ez igaz. Őszintén szólva én babelt most csak itthon használok, és nem tömörítem a kódot vagy változtatok nevet, csak a fícsöröket próbálom ki egy hobbi projekt keretein belül. Igazából fejlesztenem kellene a fejlesztési módszeremen. :DDD

    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

    Fejlesztés során egyből áttolod uglifyn a kódot?

    Nem, de ha a működő kódról jelentenek valami hibát, akkor jó lenne, ha az eredeti fájlok neveit meg az azokban lévő sort tartalmazná, nem az agyoncsomagolt fájl első sor x-edik oszlopát, amiből nem egyszerű kikeresni.

  • inf3rno
    nagyúr

    Nem semmi, én eddig nem tudom mikor jutottam volna el. :DDD Marad akkor a sima gulp-browserify, nekem jelenleg még tökéletes megteszi.

    Munkahelyen is használod a Jasminet, vagy csak otthon?

    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á.

  • inf3rno
    nagyúr

    A VM-el az a bajom, hogy ha a legkisebb OS-t is teszem fel akkor is sok helyet foglal, viszont ott nincs megfogva a kezem, mert ki tudom használni az OS lehetőségeit. A Java is VM-t használ amúgy aminek a neve igen találóan JVM lett, ezért is platform független. Várom, hogy kicsit jobb legyen ez a Docker, mert most még eléggé bugos pár helyen, de szerintem jó lesz.

    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]

  • inf3rno
    nagyúr

    Windowson próbáltam igen. Na mindegy, csak eljutottam odáig, hogy felszemeteltem a gépemre a Jenkins-t mert szükség törvényt bont. :D

    Közben átgondoltam, hogy mire jó a Docker. Bár nem vagyok benne biztos, hogy tényleg így működik. :DD

    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.

  • inf3rno
    nagyúr

    Kipróbáltam a Docker-t hát igazából elég sok a negatív tapasztalatom vele. Feltelepítettem járt hozzá egy Kinematic névre keresztel GUI alpha verzióval. Eddig nagyon jó is volt, tényleg szép letisztult külső könnyű használat, beépített log felület. Feltettem a Jenkins-t meg akkor már pár más dolgot is kipróbáltam. Működött is, majd elszállt egy connectionEx tcp hibával, kerestem rá pár megoldást nem működött semmi. Újratelepítettem, ment egy darabig meg megint hiba. Újratelepítettem és egyből hiba, szóval felhagytam vele.

    Viszont a másik probléma, Jenkins-t használ valaki? Letöltöttem hozzá a Go plugin-t és elszáll az egész. A beállításoknál folyamatosan BETÖLTÉS-t ír ki és használhatatlan, de ha kikapcsolom a plugin-t akkor megy mint régen.

    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.

  • inf3rno
    nagyúr

    Kipróbáltam a Docker-t hát igazából elég sok a negatív tapasztalatom vele. Feltelepítettem járt hozzá egy Kinematic névre keresztel GUI alpha verzióval. Eddig nagyon jó is volt, tényleg szép letisztult külső könnyű használat, beépített log felület. Feltettem a Jenkins-t meg akkor már pár más dolgot is kipróbáltam. Működött is, majd elszállt egy connectionEx tcp hibával, kerestem rá pár megoldást nem működött semmi. Újratelepítettem, ment egy darabig meg megint hiba. Újratelepítettem és egyből hiba, szóval felhagytam vele.

    Viszont a másik probléma, Jenkins-t használ valaki? Letöltöttem hozzá a Go plugin-t és elszáll az egész. A beállításoknál folyamatosan BETÖLTÉS-t ír ki és használhatatlan, de ha kikapcsolom a plugin-t akkor megy mint régen.

    Melyik oprendszeren próbáltad?

  • inf3rno
    nagyúr

    Nézem közben, hogy cisz (bocs) van linux-on is valamilyen formában. [link] Talán majd egyszer. Én most jól elvagyok node-al. :-)

  • inf3rno
    nagyúr

    Android az nem rossz, én egy kicsit foglalkoztam vele. Szerver kommunikációig jutottam, kamerát meg hasonlókat már nem kezeltem. Szerver oldalon amit egyszer ki szeretnék próbálni itthon az a Django lesz, csak jussak el odáig. :DDD Nodejs-hez milyen frameworköt használsz? Express?

    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... :D Ú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

    "Nem tudom mások hogy írnak keretrendszereket, de nekem mindig kell 2-3-4 újraírós ciklus"

    Minden egyes alkalommal. :DDD

    Nehezebb súlyú szerver oldalt is próbáltál? C#, Java?

    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

    Miért nem próbáltál ki más nyelvet szerver oldalon? Igaz amit mondasz, pár cikket és reddit posztot én is olvastam a témában, hogy a PHP csak úgy létrejött valahogy.

    Nekem nincs sok tapasztalatom benne, főiskolás évek alatt CodeIgnitert nyúztam, végzés óta pedig Laravel. Én úgy gondolom a rossz hírnévhez lehet a sok kontár pistike "programozó" járul hozzá. Mondjuk én is szívesen kipróbálnék mást is, sok féle lehetősége van már az embernek. Nodejs-t próbáltad már esetleg?

    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.

  • inf3rno
    nagyúr

    Csak érdekel, hogy ezeket így hogyan szoktátok megcsinálni, ugyanis nekem most Win7 + Kali van a laptopomon. Win7 alatt megy a PHP PHPstorm alatt Go webStorm alatt Kali alatt meg ami webprog kurzusra kell Java GWT. Már így is annyira tele van szemetelve a laptopom, hogy alig látom át mi merre van, ezért nem tudom elképzelni mit csináljak más dolgok tesztelésére. A virtuális gépek se nagyon játszanak ugyanis 120GB-os SSD-m van ami nem épp egy leányálom két oprendszer mellett. Szóval érdeklődnék, hogy ezt mind hogyan szoktátok megoldani.

    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. :DDD 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

    Mindenki fúj a PHP-ra, mondjuk jómagam nem nagyon dolgoztam még vele. Neked mi a konkrét problémád vele?

    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

    Nem semmi, én eddig nem tudom mikor jutottam volna el. :DDD Marad akkor a sima gulp-browserify, nekem jelenleg még tökéletes megteszi.

    Munkahelyen is használod a Jasminet, vagy csak otthon?

    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... :D 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

    Igen, ezt én is olvastam, de nekem csak arra kell, hogy összemeccselje a modulokra szedett kódot. Esetleg találtál mást ez helyett?

    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

    Igen, ezt én is olvastam, de nekem csak arra kell, hogy összemeccselje a modulokra szedett kódot. Esetleg találtál mást ez helyett?

    Még nem, de ma este kipróbálom, hátha sima browserify-al is működésre tudom bírni.

  • inf3rno
    nagyúr

    Szállítom az ígért kódot. :)

    Szóval az volt a baj, hogy sima browserifyn akartam használni a babelifys transformot, ezt kellett lecserélni a gulp-browserifyre.

    Így néz ki most a task, kipróbáltam, nekem működik a dolog:

    var gulp = require('gulp');
    var sass = require('gulp-sass');
    var browserify = require('gulp-browserify');
    var babelify = require('babelify');

    gulp.task('js', function () {
    gulp.src('./resources/assets/js/*.js')
    .pipe(browserify({
    transform: ['babelify']
    }))
    .pipe(gulp.dest('./public/_assets/js'))
    });

    gulp.task('js-w', function () {
    gulp.watch('./resources/assets/js/*.js', ['js']);
    });

    Webpackot még nem próbáltam, csak olvastam róla.

    A gulp-browserify-al a helyedben vigyáznék. Most nézem, hogy 2 éve nem tartják karban, és azt írják, hogy nem is fogják már. [link]

  • 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

    Tyűűű, ehhez sajnos nem tudok hozzászólni. :DDD

    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

    Szállítom az ígért kódot. :)

    Szóval az volt a baj, hogy sima browserifyn akartam használni a babelifys transformot, ezt kellett lecserélni a gulp-browserifyre.

    Így néz ki most a task, kipróbáltam, nekem működik a dolog:

    var gulp = require('gulp');
    var sass = require('gulp-sass');
    var browserify = require('gulp-browserify');
    var babelify = require('babelify');

    gulp.task('js', function () {
    gulp.src('./resources/assets/js/*.js')
    .pipe(browserify({
    transform: ['babelify']
    }))
    .pipe(gulp.dest('./public/_assets/js'))
    });

    gulp.task('js-w', function () {
    gulp.watch('./resources/assets/js/*.js', ['js']);
    });

    Webpackot még nem próbáltam, csak olvastam róla.

    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

    Időközben megoldódott a probléma. Sima browserify helyett gulp-browserifyt kell használni, persze a task is változik. Most nem vagyok otthon, nem tudok kódot mutatni, de ha érdekel a megoldás akkor holnap bemásolom ide is.

    Szerk.: köszönöm a válaszokat amúgy. :)

    Persze, érdekel. Nézem közben, hogy van ilyen is, hogy webpack. Próbáltad már azt is?

  • inf3rno
    nagyúr

    Sziasztok,

    Használta már valaki akár kipróbálás szinten a gulp-babel-browserify kombót? A gulpot és browserifyt már sikeresen működésre tudom bírni, de amikor a babelify transform képbe jön, elszáll egy ilyen hibával: browserify(...).transform is not a function.

    Google haverom talált pár példát, sajnos mindegyiknél ezt dobja.

    Maga a task:

    gulp.task('js', function () {
    return browserify({ entries: './resources/assets/js/*.js', debug: true })
    .transform(babelify)
    .bundle()
    .pipe(source('bundle.js'))
    .pipe(gulp.dest('./public/assets/js'));
    });

    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

    Sziasztok,

    Használta már valaki akár kipróbálás szinten a gulp-babel-browserify kombót? A gulpot és browserifyt már sikeresen működésre tudom bírni, de amikor a babelify transform képbe jön, elszáll egy ilyen hibával: browserify(...).transform is not a function.

    Google haverom talált pár példát, sajnos mindegyiknél ezt dobja.

    Maga a task:

    gulp.task('js', function () {
    return browserify({ entries: './resources/assets/js/*.js', debug: true })
    .transform(babelify)
    .bundle()
    .pipe(source('bundle.js'))
    .pipe(gulp.dest('./public/assets/js'));
    });

    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. :D

  • inf3rno
    nagyúr

    Őszintén szólva én csak Chrome alatt próbáltam ki pár dolgot, éles projekten még nem mertem bevetni. De ha jól emlékszem az async functionök még a Babelben is csak mint kísérleti dolog szerepelnek.

    IE supportot tekintve azt hiszem IE9 az ami még jobban támogatva van, a 8 pedig mintha csak részben lenne támogatott. Meddig gondoltad az IE kompatibilitást?

    Tőlem edge is lehet. Async function nincs egyikben sem, ahogy Object.observe sem... Elvileg az előbbit valahogy implementálni lehet ES5-ben is, az utóbbira viszont úgy tudom, hogy nincs polyfill. Azt hiszem kipróbálom valamikor babel-t.

  • inf3rno
    nagyúr

    Megnézem mik a lehetőségeim. Semmiképp sem lesz sync az ajax hívásom. Most a babel.js-t próbálgatom egy hobbi projekt keretein belül, szóval ennek lehetőségeit nézem most, kutakodok. :)

    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

    onchange-et onkeyup-ra cseréld le.
    Amúgy az előttem szólónak igaza van, sokkal szebb, ha eventlistenert állítassz be.
    Google bácsi elég hasznos válaszokat ad a "javascript event listener keyup" és hasonló kifejezésekre, ha csak js-t használsz.

    keyup azért nem jó, mert ha csak egérrel másolják be az értéket, akkor nem történik semmi.

  • inf3rno
    nagyúr

    Van olyan megoldás, ahol ha új érték kerül be azonnal ajax postol? Mert ezzel az a gond, hogy ki kell menni a fókuszból.

    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

    Csak kiegészítésképpen: az inlne event handler-től sokkal szebb (jobb, és általánosabb) egy event listener használata. Szerintem. :P Erősítsen meg ebben valaki pls.

    Megerősítve. :-)

  • inf3rno
    nagyúr

    Sziasztok!

    A segítségeteket szeretném kérni egy aprócska problémához:

    weblapot készítek, adott egy ' index.html ' ami meghív egy ' general.js ' scriptet, ebben a script-ben az alábbihoz hasonló sorok találhatóak:

    $(document).ready(function() {$('#mm1').click(function() {$('#content').load('xyz.html');}); });

    és ezzel zárul:

    "
    $(document).ready(function() {

    $('#example tr').click(function() {
    var href = $(this).find("a").attr("href");
    if(href) {
    window.location = href;
    }
    });

    $('#example tr').hover(function() {
    $(this).css('cursor','pointer');
    });

    }); "

    A problémám az lenne, hogy a böngészőben ha a vissza gombra kattolok, konkrétan nem történik semmi, következő kattintásra pedig konkrétan vissza dob az előző oldalra - bármi is volt az -

    válaszotokat előre is köszönöm :R

    Ajax-al tölti be az oldalt. A history-ba meg betesz egy bejegyzést pushState-el. Ez a window.location = href; meg elég gánynak számít, ha közben ajax-al töltögetsz be dolgokat.

  • 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

    Protip: for ..in + hasOwnProperty helyett Object iteration-re:

    Object.keys(obj).forEach(function(key) {
    // obj[key]
    })

    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

    A kliens altal tamasztott kovetelmenyekkel altalaban. A business logic neha-neha annyira bonyolult es a specifikacio annyiszor valtozik menet kozben, hogy eleg nehez egy tenyleg jol mukodo feature-t osszehozni.

    Illetve a oldalak kozti navigaciot sokszor eleg nehez hibamentesen osszehozni mert a kapcsolati halo eleg bonyolult es a statemanagement is problemassa valik(hat).

    Ami mar inkabb programozas kozeli az a kulonbozo platformok tamogatasanak igenye es az ebbol fakado gondok. Kulonbozo WebView verziokat kell tamogatni es kulonbozo Oprendszereket es nem minden mukodik ugyanugy ezeken. Ezekkel nagy szivas van. Erdekes nyelvi szinten ebbol nincs problema. Szinte minden tamogatott environmenten mar olyan WebView van ami az Ecma 5.1-et teljes koruen tamogatja szv ebbol nincs gond.

    Kb ugy ennyi.. :)

    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 kliens altal tamasztott kovetelmenyekkel altalaban. A business logic neha-neha annyira bonyolult es a specifikacio annyiszor valtozik menet kozben, hogy eleg nehez egy tenyleg jol mukodo feature-t osszehozni.

    Illetve a oldalak kozti navigaciot sokszor eleg nehez hibamentesen osszehozni mert a kapcsolati halo eleg bonyolult es a statemanagement is problemassa valik(hat).

    Ami mar inkabb programozas kozeli az a kulonbozo platformok tamogatasanak igenye es az ebbol fakado gondok. Kulonbozo WebView verziokat kell tamogatni es kulonbozo Oprendszereket es nem minden mukodik ugyanugy ezeken. Ezekkel nagy szivas van. Erdekes nyelvi szinten ebbol nincs problema. Szinte minden tamogatott environmenten mar olyan WebView van ami az Ecma 5.1-et teljes koruen tamogatja szv ebbol nincs gond.

    Kb ugy ennyi.. :)

    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

    En Dartoztam egy darabig es nagyon tetszett, tenyleg, jo kis nyelv az, csak nem talalta meg a helyet a vilagban, de maga a nyelv az fasza :) Ennek ellenere most egy baromi nagy JS heavy projekten dolgozom es latom, hogy a tenyleges problemak csak egy baromi kis szeletet jelentik a tipusossagbol adodo gondok?. Nem neveznem gondoknak oket..mondjuk ugy hogy baromi ritkan van abbol gond, hogy a JS dinamikusan tipusos az esetek kb 1%-ban szamit. Es ha azt vesszuk alapul, hogy jo JS fejlesztoink vannak akkor egesz egyszeruen nem lenne elonye egy TypeScriptnek egy vanilla JS-hez kepest :/

    Elhiszem. :-)

    Mivel vannak nagyobb gondok, ha nem céges titok?

  • inf3rno
    nagyúr

    Nem szabad kizarolag sem typeof -ot sem instanceof -ot hasznalni type checkingre. Van amire ez jo, van amire az. Univerzalis megoldas nincs, peldaul amire te hasznaltad az instanceof-ot arra nem valo es nem ajanlott mert hibakhoz vezethet.

    instanceof and multiple context (e.g. frames or windows)

    Different scope have different execution environments. This means that they have different built-ins (different global object, different constructors, etc.). This may result in unexpected results. For instance, [] instanceof window.frames[0].Array will return false, because Array.prototype !== window.frames[0].Array and arrays inherit from the former. 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. For instance, you can securely check if a given object is in fact an Array using Array.isArray(myObj)

    Epp ezaz, hogy nem muszaj mindig tipusellenorizni, ezert is irtuk itt tobben is, hogy a !x es tarsai hasznalata javvallott! ;)
    De asszem mar boven korul lett ragva a topic :))

    Udv

    inf3rno: typescript, dart, coffee, elm.. egyeni preferencia kerdese, szerintem ezek csak akkor hasznosak ha Java-n nevelkedett embernek kell JS kodot irnia. <tapasztalat>

    "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

    Nem szabad kizarolag sem typeof -ot sem instanceof -ot hasznalni type checkingre. Van amire ez jo, van amire az. Univerzalis megoldas nincs, peldaul amire te hasznaltad az instanceof-ot arra nem valo es nem ajanlott mert hibakhoz vezethet.

    instanceof and multiple context (e.g. frames or windows)

    Different scope have different execution environments. This means that they have different built-ins (different global object, different constructors, etc.). This may result in unexpected results. For instance, [] instanceof window.frames[0].Array will return false, because Array.prototype !== window.frames[0].Array and arrays inherit from the former. 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. For instance, you can securely check if a given object is in fact an Array using Array.isArray(myObj)

    Epp ezaz, hogy nem muszaj mindig tipusellenorizni, ezert is irtuk itt tobben is, hogy a !x es tarsai hasznalata javvallott! ;)
    De asszem mar boven korul lett ragva a topic :))

    Udv

    inf3rno: typescript, dart, coffee, elm.. egyeni preferencia kerdese, szerintem ezek csak akkor hasznosak ha Java-n nevelkedett embernek kell JS kodot irnia. <tapasztalat>

    "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

    Ezeknek nem az az ertelme, hogy tipusossa tegyunk egy dinamikusan tipusos nyelvet, ennek ondokumentacio meg self validation miatt van ertelme.

    Pl ha van egy fuggveny ahol azt varod hogy tombbel hivjak meg, de biztosra akarsz menni, akkor

    rossz esetben igy irod meg

    function doStuff(inputArray) {
    return inputArray.map(makeChange);
    }

    Jo esetben pedig igy

    /**
    * @param {Array} inputArray
    * @return {Array}
    */
    function doStuff (inputArray) {
    if (!inputArray || !utils.isArray(inputArray)) {
    return [];
    }
    return inputArray.map(makeChange);
    }

    Ondokumentalas, es annak a kodbeli leirasa, hogy te mint programozo milyen mukodesre irtad meg a fuggvenyt. Persze lehet ezt kevesbe expliciten is irni, pl:

    function doStuff (inputArray) {
    return (inputArray || []).map(makeChange);
    }

    De ez utobbi megint csak a falsy value-k ellen ved, az ellen nem ha pl egy stringet adnak meg.

    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

    Nem értem ezen mi a bad practice. Egyszerű falsy check. De ha én tudom rosszul akkor kérlek írd le miért bad practice.

    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

    A !x kifejezes nem azt jelenti, hogy x == false hanem

    The production UnaryExpression : ! UnaryExpression is evaluated as follows:

    Let expr be the result of evaluating UnaryExpression.
    Let oldValue be ToBoolean(GetValue(expr)).
    If oldValue is true, return false.
    Return true.

    A ToBoolean a falsy ertekeket konvertalja boolean false-ra amit negalni fogunk true-ra. Tehat a !x az egy falsy check es ajanlott a hasznalata ha nincs szukseg explicit check-re.

    Nekem még mindig azt jelenti, hogy
    x == false
    Boolean(x) === false
    !!x === false
    !x === true

    és így tovább, de hallgatom az ellenpéldákat, hogy ezek mikor nem adnak azonos eredményt, mint a !x.

  • inf3rno
    nagyúr

    Amit te szeretnél az egy single page application, amit Karma jól be is mutatott. Annyit tennék még hozzá, hogy ebben az esetben a helyetekben a drupalt abszolút mellőzhetném, csak rest apu kell alá. De érted, így meg bukod a komplett Cms funkcionalitást. Neked kell dönteni, marad a cms bubusság és szar végeredmény gyorsan összekattogtatva, vagy megírjátok normálisra spa-ként, mondjuk 10-szer akkora idő befektetéssel.

    Esetleg ezt megpróbálhatja, ha már PHP+CMS+SPA: [link], hátha bejön neki.

  • inf3rno
    nagyúr

    Köszi, próbálkozom :B

    Egyébként szoftverfejlesztő vagyok, jelenleg szabadúszom (egy nagy Angular projekten dolgozom főleg most), azelőtt Android/WP/iOS fejlesztőként dolgoztam, azelőtt salátában sokmindent (BI, Java SE alapon hatalmas rendszerek foltozása, SIM programozás), azelőtt meg Symbian fejlesztő voltam. Keresem a magasabb rendű rendezőelveket a tervezés/fejlesztés mögött (ld. Martin Fowler munkásságát, számomra példakép), a sok lexikális dolog meg egyszerűen rámragad. Kivéve a PHP-t, azzal taszítjuk egymást :DDD

    Nem csodálom. Én toltam PHP-t pár évig, van 1-2 szép oo lib benne, de a maradék azért bőven hagy kívánnivalót maga után.

  • inf3rno
    nagyúr

    Segítséget kérnék megérteni a lenti kódot. Működik, de nem értem hogyan :)
    (nodejs stream-adventure / html stream feladat)

    var trumpet = require('trumpet');
    var through = require('through2-map');
    var tr = trumpet();

    tr.pipe(process.stdout);

    tr.selectAll('.loud', function(data) {
    var stream = data.createStream();
    stream.pipe(through(function(chunk) {
    return chunk.toString().toUpperCase();
    })).pipe(stream);
    });

    process.stdin.pipe(tr);

    "tr.selectAll": kap egy szűrőt és egy callback-et. A callback fv-ben definiálok egy új változót, pipeolom through-ba ahol átalakítom, majd önmagába pipeolom vissza. Eddig tiszta sor.
    Viszont hogy kerül vissza? Closure-ben lett létrehozva és semmi függvény (ami return-ként működne) nem lett meghívva rá.
    Maga a createSteram() köti a "stream" változót closure chainen keresztül "tr"-hoz valahogy?

    Maga a createSteram() köti a "stream" változót closure chainen keresztül "tr"-hoz valahogy?
    Nagy valószínűséggel. Esetleg ha megkeresnéd a dokumentációt, ott biztosan leírják, ha van ilyen feature.

  • inf3rno
    nagyúr

    Fejlesztett már valamelyikőtök Linux Mint extension-t (applet, desklet)? Lenne pár kérdésem.

  • inf3rno
    nagyúr

    "amíg a böngészők nem támogatják es6-ot"

    Szerintem ez téves hozzá állás. Olyan szempontból, hogy ebben a szakmában nem árt, ha naprakész az ember. A teljes ES6 támogatásra még várni kell, illetve az visszafelé nem tudom hogyan fog működni, ezzel pedig a régebbi böngészőkre is tudod használni az ES6 fícsöröket.

    Én a fentebb említett hobbi projekt keretein belül pont a browserifyt, babelt és reactot próbálgatom. :)

    (#5412) martonx: ES7 pár funkciója még kísérleti fázisban van a Babelben. ES6 (ES2015) most kezd divatba jönni, a hype vonat már elhagyta az állomást. :))

    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

    Igazából ez is normál JS, csak az ES6 (ES2015 újabb nevén) fícsöröket lefordítja ES5-re. Például ha azt írod, hogy Class App { .. }, akkor abból egy var App = (function() { ... })(); lesz.

    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

    Megnézem mik a lehetőségeim. Semmiképp sem lesz sync az ajax hívásom. Most a babel.js-t próbálgatom egy hobbi projekt keretein belül, szóval ennek lehetőségeit nézem most, kutakodok. :)

    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

    Sziasztok!

    Tudom, h az if alap, de én is full alap (kuka) vagyok a témában... :U

    Az lenne a kérdésem, h ifben hogy lehet megadni, h mondjuk akkor fusson le a benne lévő kódrész, ha xy=0, vagy mondjuk yx=0?

    Az megvan, h egy változó, meg az "és" is, csak a vagy nincs meg.

    Létezik ilyen? :F

    Köszi! :R

    if (xy == 0 || yx == 0)

    de ha tudod, hogy csak számok lehetnek, akkor

    if (!xy || !yx)

    elképzelhető, hogy bináris operátorokkal trükközve még gyorsabb, de ahhoz nem értek, és valszeg neked sem lesz rá soha szükséged, ha webre tákolsz.

  • inf3rno
    nagyúr

    Sziasztok!

    A következőn töröm a fejem:

    Van egy függvényem, aminek a return értéke legyen mondjuk a username változó. Ezt a user nevet én a fv. elején már létrehozom, érték nélkül. Rögtön a létrehozás után egy ajax kéréssel értéket is adok ennek a változónak. A problémám az lenne, hogy a return előbb adja vissza az undefined értéket, mint ahogy az ajax be tudná állítani azt.

    Maga az AJAX jQuery útján történik, így egy lehetséges megoldás az async: false beállítása. Csak ekkor a main-thread foglalt lesz, ezért már a böngésző is sír a konzolban. Esetleg tudtok valami megoldást erre?

    Példakód.

    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

    Én inkább angularral mennék/mentem neki, mert bár az is 125 KB (vö. D3 150 KB), ezért a méretért cserébe a teljes feladatot, no meg az esetleges hálózati kommunikációt, meg bármi mást ami egy teljes alkalmazáshoz kell, meg lehet csinálni könnyen vele.

    Akkor hűltem el nagyon, amikor próbáltam D3 + NVD3 + angular direktívákkal összerakni háromféle chartot, 500 KB-nyi lib olyan chartokért, amik közelében sincsenek a designer igényeinek... Ezért írtam meg inkább kézzel.

    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 egy brutál nagy lib egy ilyen egyszerű feladathoz. Mostanában elég sokat csináltam egyedi chartokat egy Angular alapú projektben (közvetlenül SVG-t állítok elő template-ből), és teljes nyugalommal jelentem ki, hogy az adat hatására frissülő szintező összesen 20 sor kódból elkészíthető animáció híján :)

    Mondjuk tiszta lappal indulva szerintem az egy hét bőven kevés.

    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

    Sziasztok/köszöntök minden tisztelt fórumlátogatót!

    Üzenetem kicsit hosszú lesz, és alkotása közben már most ver a szívem, hogy esetleg az üzenetem elolvasása végére elfogtok küldeni a jó fenébe, mert esetleg olyan munkát kérnék ami vagy nem olyan egyszerű, vagy ezt ingyen nem fogja nekem senki megcsinálni. Én bízom ezek ellenkezőjébe, már csak azért is mert azzal kezdeném hogy valójában nem is komplett menüvel ellátott weblap kellene nekem.

    Na de kezdem az elején. Arról van szó, hogy én nyár eleje óta egy projecten dolgozom. Ez egy saját mondhatni megálmodott project, amely szeptemberben kerül(ne) bevetésre. Tehát addig van úgymond időm, hogy megvalósítsam. A project 5 blokkra van bontva, amelyből 3 kész van. A kérésemmel megfogalmazandó feladat lenne a 4. Ez a 4. blokk egy webes felületen működő szintező lenne. Én neveztem el szintezőnek de ez lényegtelen. A webes felülett alatt csak annyit értek, hogy egy weblapon van rajta ez a szintező, de a weblap gyakorlatilag ezen kívül semmi mást nem tartalmaz. Tehát semmi menü meg bisz-baszok.

    Mi is a problémám a szintező megvalósításával? A válasz roppant egyszerű: Nem értek a programozáshoz. Pontosabban a webprogramozáshoz nem értek, mert a szintező az nem egy egyszerű HTML kód, hanem annál több (de ezt ti jobban tudjátok). Az ok, amiért ide jöttem tehát, hogy ez a szintező nekem nagyon nagyon kéne, nem tudom jobban körberajzolni. Találtam ugyan sablonokat (LINK), de sajnos én nem tudom összehozni úgy a kódot hogy olyan legyen amilyet én elképzeltem.

    És akkor jöjjön az általam megálmodott szintező terve:

    A rajzon tehát leírtam hogy mi hogyan működne benne.

    SZUMMA: Tehát nekem egy üres szimpla weboldalon kellene hogy megjelenne egy ilyen animált progress bar, a rajzon megadott működési elv szerint. A Progress bar alatt pedig a rajzon feltüntetett 2 db szimpla kis textbox kéne a megadott működési elvekkel.

    Nem is tudom hogy merjek kérni így bármit is. De ha esetleg lenne köztetek, aki ezt megtudná csinálni nekem, aranyszobrot fogok neki állítani. Amennyiben ez nem lehetséges, bármilyen segítséget elfogadok, de kétlem hogy lenne olyan program amivel ezt meglehetne csinálni programozás nélkül.

    Még egyszer előre is köszönöm! :R :R :R

    U.i.: Amennyiben üzenetemnek más topicban lenne a helye, kérem jelezzétek! :R :R :R

    U.i.: Amennyiben van kérdés a rajzzal kapcsolatban szívesen válaszolok! :R :K

    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

    Virtualizált Androiddal nem foglalkoztam még. Az évek során Windows hostokról (XP, Vista, 7, 8.1) adtam már át Linux (Ubuntu, Xubuntu, CentOS, Manjaro) és Windows (XP, 7, 8.1, 10, 2012 Server) guesteknek USB-s perifériákat (webkamera, fényképezőgép, tuner, kriptotoken).

    A periféria sikeres átadásának természetesen feltétele, hogy a guest rendszerben legyen hozzá driver, az Android guest itt nagyon hamar el tud bukni, mert simán elképzelhető, hogy a kernelbe nincsen belefordítva a szükséges driver (ezen csak saját kernel fordításával tudsz továbblépni). Az ellenben nem feltétel, hogy a hoston legyen hozzá a VMware úgy is át tudja adni (például egy őskövület fényképezőgépről, amelyhez nincsen 32 bites XP-nél frissebb driver, virtualizált Linuxon keresztül tudom letölteni a képeket).

    De eddig WinJS-ről volt szó, annak mi köze az Androidhoz?

    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

    Virtualizált Androiddal nem foglalkoztam még. Az évek során Windows hostokról (XP, Vista, 7, 8.1) adtam már át Linux (Ubuntu, Xubuntu, CentOS, Manjaro) és Windows (XP, 7, 8.1, 10, 2012 Server) guesteknek USB-s perifériákat (webkamera, fényképezőgép, tuner, kriptotoken).

    A periféria sikeres átadásának természetesen feltétele, hogy a guest rendszerben legyen hozzá driver, az Android guest itt nagyon hamar el tud bukni, mert simán elképzelhető, hogy a kernelbe nincsen belefordítva a szükséges driver (ezen csak saját kernel fordításával tudsz továbblépni). Az ellenben nem feltétel, hogy a hoston legyen hozzá a VMware úgy is át tudja adni (például egy őskövület fényképezőgépről, amelyhez nincsen 32 bites XP-nél frissebb driver, virtualizált Linuxon keresztül tudom letölteni a képeket).

    De eddig WinJS-ről volt szó, annak mi köze az Androidhoz?

    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

    Rendelsz Kínából USB-s BT4.0 adaptert (bár itthon sem sokkal drágább), azután VMware Playerben telepítesz Windows 8-at, és ott át tudod adni* neki az USB-s eszközt. Ha van elegendő mennyiségű memóriád és megfelelő processzorod, akkor a legkényelmesebb VM alól végignyomni a teljes fejlesztést.

    * elvileg ilyet a VirtualBox is tud, csak kölcsönösen nem kedveljük egymást, így olyan messzire kerülöm, amilyen messze lehet ;]

    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

    Sziasztok, egy olyan js komponens kellene, ami egy megadott lista elemeit automatikusan pozícionálja egy elipszis kerülete mentén. Azaz lenne egy mondjuk X magas Y széles elipszis, és lenne egy tömbnyi div element, amiket abszolút kellene pozícionálni egymástól azonos távolságra az ellipszis mentén.
    Létezik ilyen js lib, ami ezt kikalkulálgatja, a megadott elipszis adatai és a div elemszáma alapján, vagy meg kellene írnom?

    Van egy csomó ilyen lib, régebben láttam nem egyet, de már nem emlékszem a nevükre. Nézz körül jquery plugin-ek és d3 környékén, 100%, hogy lesz ilyen. Megírni sem egy nagy szám egyébként, alap matek.

  • 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

    Rendelsz Kínából USB-s BT4.0 adaptert (bár itthon sem sokkal drágább), azután VMware Playerben telepítesz Windows 8-at, és ott át tudod adni* neki az USB-s eszközt. Ha van elegendő mennyiségű memóriád és megfelelő processzorod, akkor a legkényelmesebb VM alól végignyomni a teljes fejlesztést.

    * elvileg ilyet a VirtualBox is tud, csak kölcsönösen nem kedveljük egymást, így olyan messzire kerülöm, amilyen messze lehet ;]

    Fura, pedig sok helyről hallottam, hogy a VirtualBox a tuti.

  • inf3rno
    nagyúr

    Bármi ötlet, hogy win7-ről hogyan tudom megoldani a winjs befordítást és tesztelést? :D 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? :D

    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?

  • inf3rno
    nagyúr

    SSD van WebStorm-ért meg nem fizetek mikor vannak ingyenes alternatívák. :)

    (#5354) Zedz

    NetBeans. :D

    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.

  • inf3rno
    nagyúr

    Nekem SSD van alatta, NodeJS-el próbáltam és pár letöltött modul volt még amit egyszerre kellett berántania indításkor, de ezen kívül más nem ment alatta. Nem tudom miért, de nagyon zabálta a memóriát. Így maradt a Sublime vagy NetBeans. Valaki használta már a GitHub Atom-ját? Még azt próbálgatom most, de tudásilag szinte a Sublime buta szintjén van. Nem tudom, hogy bővítsek-e memóriát, ugyanis itt van az SSD.

    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

    Az SSD valószínűleg elfedi a memóriahiány miatti vergődést (én 4 GB memória mellett kizárólag HDD-n próbáltam). 4 GB-tal sokkal lassabban indul a VS2013, mint egy VS2010, sokkal lassabban tölt be 30-40 projektes solutionöket, és vannak olyan editorok, amelyek használatához a vergődés miatt ekkor fokozott türelem kell (a XAML például ilyen), szóval a lassúság érzete lehet projekttípustól függő is. Én ezért aztán reflexből 8 GB memóriát adtam legutoljára a VM-nek, amikor ki kellett deríteni egy OS specifikus nyűgöt, és szükség volt adott platformon ehhez fejlesztői környezetre :)

    A TFS-es rész innen vettem, VS2015-ben szigorítottak rajta (bár ez engem az otthoni gépen nem fog érinteni, nem kedvelem a beépülő verziókezelőket, ha SVN és Git repóid vannak, akkor funkcionalitásban és megbízhatóságban a SmartSVN és SmartGit közelében sincsen egyik sem).

    Ha így van, akkor gondolom egy idő után meg is eheti az SSD-t.

  • inf3rno
    nagyúr

    A VS2010 volt az utolsó Visual Studio, amelyik még beérte 4 GB memóriával. Ezután alaposan hozzányúltak az IDE alapjaihoz, ami azt eredményezte, hogy 8 GB alatt kínszenvedés használni, de ha van ennyi memóriád, akkor a VS2012 és utódai érezhetően sokkal-sokkal gyorsabbak ugyanazon a gépen, mint a VS2010.

    A Community Edition pedig lényegében egy Professionalnek felel meg némi tudásbeli (nincsen TFS, CodeLens) és némi licencbeli (egyéni fejlesztők és legfeljebb 5 fős cégek használhatják) korlátozással.

    Fura, ha azt nézem, hogy nálam a WebStorm 250-ről indul, és onnan megy fel projekt méret függően. Két megnyitott projektnél is csak 400Mb-ot eszik most. Ehhez képest a 8Gb azért nagyon az alja. Nincs is annyi a gépben, mert eddig nem kellett. :DDD

  • inf3rno
    nagyúr

    Azért próbálj már meg WebStormmal windows app-ot fejleszteni, mindenféle emulátor nélkül :P
    Az ingyenes VS2015 meg egészen ott lesz a szeren.

    Elméletileg van készülőben automatikus kiegészítés, gyakorlatilag meg valamiért nem mergelték bele fő szálba a definitelyTyped-nál. Nem értem, hogy mi van, rákérdeztem... Eddig semmi válasz. [link] Így tényleg nem túl hasznos a Webstorm WinJs-hez.

  • inf3rno
    nagyúr

    Visual Studionak van ingyenes változata, innen tudod letölteni. Ha vársz még egy kicsit, hamarosan kijön ( vagy már jött? ) a 2015-ös verzió is. :)

    Ha minden igaz már NodeJS support, meg efféle finomságok is vannak már benne.

    Tudom, hogy van, de nem szeretnék Visual Studio-t használni. Webstorm-ot használok, megszoktam, fizettem érte, szeretem. Ennyi. Az ingyenes VS-t kipróbáltam annak idején, nagyon lebutított volt emlékeim szerint, de ez már évekkel ezelőtt volt.

  • inf3rno
    nagyúr

    A WinJS alkalmazáshoz lehet más nyelven írt WinRT komponenseket csatolni, én lehet inkább átvinném a problémát a C# világba. A BLE kezelés lépéseit egyébként ez a blog leírja - még az is lehet, hogy át lehet ültetni JS-be soronként.

    Ha szerencséd van, a kütyü az összes fontos paramétert kiajánlja GATT attribútumokként, amiket tudsz olvasni vagy írni. Ha nincs szerencséd, és pl. a FitBithez hasonlóan egy titkosított blobként tárolnak mindent, akkor elég esélytelen a feladat.

    Szerk.: Most látom, hogy WP-s blogot linkeltem be. Az elv meg a használt osztályok ettől még hasonlóak. Morzsák meg MSDN-en is vannak.

    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

    Miért WinJS-sel csináljátok? :) Csak kíváncsi vagyok, mert nálunk is épp hegesztünk egy Win 8 appot, és azt hittem az országban egyedül szopunk ezzel. :DDD

    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? :DDD

    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. :D

Új hozzászólás Aktív témák

Hirdetés