- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Luck Dragon: Asszociációs játék. :)
- Archttila: SMART tesztelés automatizálva: smartctl poller script Zsh-ban, RPi-re
- gban: Ingyen kellene, de tegnapra
- btz: Internet fejlesztés országosan!
- sziku69: Fűzzük össze a szavakat :)
- Parci: Milyen mosógépet vegyek?
- bacsis: Gyere el a 11. BRSZK-ra!
- Luck Dragon: Alza kuponok – aktuális kedvezmények, tippek és tapasztalatok (külön igényre)
- MasterDeeJay: Low budget (50.000 forint) light gémer gép összerakása
-
LOGOUT
LOGOUT
Új hozzászólás Aktív témák
-
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.
-
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] -
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.
-
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.
-
Sk8erPeter
nagyúr
"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.
-
Sk8erPeter
nagyúr
É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."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.
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.![;]](//cdn.rios.hu/dl/s/v1.gif)
) -
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.
-
-
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.
-
É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. -
Sk8erPeter
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.
-
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.
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. 
-
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.
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.
-
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á.
-
PumpkinSeed
addikt
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.
-
PumpkinSeed
addikt
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.
-
PumpkinSeed
addikt
-
PumpkinSeed
addikt
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.
Ezt a dockert akkor kipróbálom.
-
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.
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.
Nodejs-hez milyen frameworköt használsz? Express? -
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.
"Nem tudom mások hogy írnak keretrendszereket, de nekem mindig kell 2-3-4 újraírós ciklus"
Minden egyes alkalommal.
Nehezebb súlyú szerver oldalt is próbáltál? C#, Java?
-
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.
-
PumpkinSeed
addikt
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.
-
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.
-
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.
Nem semmi, én eddig nem tudom mikor jutottam volna el.
Marad akkor a sima gulp-browserify, nekem jelenleg még tökéletes megteszi.Munkahelyen is használod a Jasminet, vagy csak otthon?
-
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.
Tyűűű, ehhez sajnos nem tudok hozzászólni.
-
Persze, érdekel. Nézem közben, hogy van ilyen is, hogy webpack. Próbáltad már azt is?
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.
-
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.
-
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.
-
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.
-
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?
Sajnos amikor keszult a projekt akkor nem igazan gondoltak fejlesztesi modszertanokra azota pedig annyira kinotte magat a projekt hogy eleg nehez (khmmm ain't noone will pay for this) akar csak egy TDD-t is bevezetni. Az eddig megirt kodbazis 90% nem tesztelheto modulokban lett megirva nem olyan szempontok szem elott tartasaval, szv fck
De azert probalkozik az ember mert igeny (most mar) lenne ra. Legalabbis fejlesztoi oldarol.Async-hez sima jQuery -> AJAX/Deferred, legacy product es mint olyan jQuery-t hasznal, sajnos
A nativ hiba az mi volt?
-
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..
-
"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.
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 :/ -
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.
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 topicUdv
inf3rno: typescript, dart, coffee, elm.. egyeni preferencia kerdese, szerintem ezek csak akkor hasznosak ha Java-n nevelkedett embernek kell JS kodot irnia. <tapasztalat>
-
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...
-
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.Hat... Chrome console ->
function x_test(val) {
console.group();
console.log(!val);
console.log(val == false);
console.groupEnd();
}
[0, null, void 0, '', Number.NaN, [], {}, 2, "test"].forEach(x_test);
// output
VM586:3
VM586:4 true
VM586:5 true
VM586:3
VM586:4 true
VM586:5 false
VM586:3
VM586:4 true
VM586:5 false
VM586:3
VM586:4 true
VM586:5 true
VM586:3
VM586:4 true
VM586:5 false
VM586:3
VM586:4 false
VM586:5 true
VM586:3
VM586:4 false
VM586:5 false
VM586:3
VM586:4 false
VM586:5 false
VM586:3
VM586:4 false
VM586:5 falseNekem ez nem ugy tunik mint ami ugyanaz lenne
-
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.
"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.
-
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.
-
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ó.
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.
-
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.
-
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).
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.
-
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).
Köszönöm a választ. Segítséged precíz, gyors, részletes. Hasonlókat kívánok!
-
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...
Az integrált BT-d is 99%, hogy belül USB porton csatlakozik az alaplapodhoz.
-
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?
-
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?
-
PumpkinSeed
addikt
"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.
-
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?
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
-
PumpkinSeed
addikt
-
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.
Nem írtad, hogy WebStormozol.
De amúgy WS után ( és a PhpStorm után, de ez mondhatni ugyan az az IDE ) szerintem a VS a legjobb. Mondjuk a WS-ben az nagyon jó, hogy hamar támogatják a trendet.(#5342) PumpkinSeed: Az én laptopomban is 4GB RAM van, meg egy gyenge B960-as Intel, de nekem a Community teljesen jól fut, úgy, hogy nagy monitorra van kötve a gép. Akkor feküdt meg a kicsike, amikor a WinJS-hez indítottam egy Win8 szimulátort az érintőkijelzőt szimulálva, és egy batár nagy SVG-vel kellett dolgoznia a gépnek.
-
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.
Ez a VS2013 Community előtt abszolút igaz volt, az ingyenes VS-ek használhatatlan szarok voltak, épp csak arra jók, hogy az ember elkezdjen pötyögni rajtuk valamit. Változnak az idők
szerencsére.
A VS2013 Community pedig a nevével ellentétben valamikor 2014 második felében jött ki, szóval ez is egész tűrhető. -
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.
Ha van WebStorm akkor nem igazán szól semmi a leváltása mellett
-
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.
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.
-
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.
-
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.
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.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
)
Gondolok itt..
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. 
Új hozzászólás Aktív témák
- EA Sports WRC '23
- Milyen videókártyát?
- Először kombinálja a Full HD-t az 1000 Hz-cel egy monitor
- Június 18-án érkezik a Hell Let Loose: Vietnam PC-re és konzolokra
- Yettel topik
- Huawei Watch Fit 5 Pro - jó forma
- AMD FX
- Lenovo IdeaPad notebookok
- A Linux megnégyszerezte magát a Steamen — a Microsoft ismét ígérget
- Lexus, Toyota topik
- További aktív témák...
- 4000GB Gen4x4 NVMe SSD, 1 év gar 4TB!!!
- SZÉP! HP ZBOOK FURY 15 G7 Tervező Vágó Laptop -70% 15,6" i7-10850H 32/512 Quadro RTX 3000 6GB FHD
- GARANCIÁLIS LEMEZES PLAYSTATION 5 SLIM CFI-2116
- NAGYKER ÁR!Sosemhasznált! HP OmniBook 5 Flip i5-1334U 8GB 512GB 14" FHD+ áthajtós-érintős Gar.: 1 év
- Macbook Pro 14" A2442 2021 M1 Pro 32/1TB Silver
- Kuriózum: Ozark Trail (amerikai) fejlámpa 600 lumen
- HP ProBook 455 G7 15,6" Ryzen 3 4300U, 8-16GB RAM, SSD, jó akku, számla, 6 hó gar
- 27% - ASUS TUF Gaming VG28UQL1A Monitor! 3840x2160 / 1ms / 144Hz / G-Sync / FreeSync BeszámítOK!
- Telefon felvásárlás!! iPhone 16/iPhone 16 Plus/iPhone 16 Pro/iPhone 16 Pro Max
- iPhone 16 pro 128GB Sivatagi Titán - 27% ÁFA (0396)
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest