-
GAMEPOD.hu
JavaScript != Java (A JavaScript nem összekeverendő a Javával, két különböző programozási nyelvről van szó!)
Új hozzászólás Aktív témák
-
Zedz
addikt
válasz inf3rno #5550 üzenetére
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.
[ Szerkesztve ]
-
Zedz
addikt
válasz inf3rno #5552 üzenetére
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.
-
inf3rno
nagyúr
Azt nézem hatalmas különbség nincsen, csak annyi, hogy streamelhetővé teszi browserify-t. Elméletileg enélkül is működnie kellett volna sima callback-el. Így azért szerintem sokkal szebb, hogy tudja a gulp src-t használni, és nem kell glob-ot meg ilyesmiket beletákolni a kódba. Majd ha kipróbálom babel-t, akkor visszatérek ehhez. A webpack-re azt mondják, hogy babel-el gyorsabban csomagol, meg hogy kisebb a minified fájlméret is. Azért nem olyan egyszerű belőni, mint a browserify-t.
Karmával van tapasztalatod? Azzal küzdök, hogy gulp task-el szervert indítsak, ami nem záródik be a gulp task végén sem. Gondolom child process-be kellene tenni valahogy, és belőni daemon-nak a child process-t. Egyelőre idáig jutottam:
var karma = require("karma"),
gutil = require("gutil");
module.exports = function (done) {
var server = new karma.Server({
configFile: "../../../karma.conf.js"
});
server.on("browser_error", function (browser, err) {
gutil.log("Karma Run Failed: " + err.message);
throw err;
});
server.on("run_complete", function (browsers, results) {
gutil.log("Karma Run Complete: " + results.failed ? "Some of the Tests Failed" : "No Failures");
done();
});
server.start();
};module.exports = function (config) {
config.set({
basePath: __dirname,
frameworks: ['jasmine'],
files: [
{pattern: 'src/nodelist.js', included: true},
{pattern: 'tests/*.js', included: true}
],
exclude: [],
reporters: ['progress'],
port: 9876,
colors: true,
logLevel: config.LOG_INFO,
autoWatch: true,
browsers: ['Firefox'],
captureTimeout: 6000,
singleRun: false
});
};Az a kínja most, hogy a teszt futása közben megakad az egész a singleRun: false miatt. Gondolom ezt a részt valahogy ki kellene szervezni child process-be, aztán megpingelni a szervert, hogy fel van e lőve. Ha igen, akkor meg hagyni, hadd dolgozzon. A gond csak az, hogy elvileg ezt a karma magától megteszi. Szóval nem tudom, hogy melyik részt lenne érdemes child process-be tenni, és hogyan kommunikálni vele. Láttam, hogy van olyan, hogy karma client, lehet, hogy a szervert miután a child process-be tettem csinálni kell egy client-et, ami majd kommunikál vele. Gondolom a fájl frissítéseket az autoWatch automatikusan megcsinálja, szóval azzal a részével nem lenne gond. Hát egyelőre zavaros, dokumentáció meg általában nem nagyon van ilyen mélyebb dolgokról. Majd feltúrom a kódot, aztán lesz valami.
[ Szerkesztve ]
Buliban hasznos! =]
-
inf3rno
nagyúr
Azt hiszem egyelőre most én is hagyom. Nem én csinálom a projektet, csak a csomagolás részébe segítek bele, aztán gondoltam legalább az legyen TDD alapon. Legalább egy pár szimpla jasmine tesztet írok majd arra, hogy megy e a böngészőben a lib vagy nem. A jquery-t akarja kiváltani vele a srác. [link]
Ha valakit érdekel, akkor karma-ban singeRun-al így oldható meg rendesen:
var karma = require("karma");
module.exports = function (done) {
var server = new karma.Server({
configFile: "../../../karma.conf.js",
singleRun: true
}, function (exitCode) {
done();
});
server.start();
};Az előző kód valamiért singleRun: true esetében ha hibás volt a teszt, akkor elszállt valamilyen gulp hibával. Nem értek a lelki világához, debugra meg most nem igazán van időm. Ennél is fontos, hogy a karma config fájlban __dirname-t használjunk, különben rossz helyet állít be basePath-nak. Ne kérdezzétek miért, valszeg ez is egy bug lehet. Már reportoltam.
[ Szerkesztve ]
Buliban hasznos! =]
-
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...
[ Szerkesztve ]
Buliban hasznos! =]
-
inf3rno
nagyúr
Egyelőre eddig jutottam vele:
var browserify = require("browserify"),
fs = require("fs");
module.exports = function () {
return browserify()
.require("./dist/nodelist.latest.node.min", {expose: "nodelist"})
.bundle()
.pipe(fs.createWriteStream("dist/nodelist.latest.bundle.js"));
};Annyi jött le, hogy a bundle() egy readable stream-et ad, amit aztán át lehet pipe-olni fájl írós stream-be. Ebben az esetben csak egy modult csomagoltam bele, és publikussá tettem, mert böngészős jasmine tesztekből akarom elérni. Ha magamnak fejlesztettem volna, akkor karma-browserify-t rakok alá, és nem mentem ki külön fájlba, de az már más kérdés.
A te régi kódod elvileg nagyjából jó, csak a glob-ot kéne hozzácsapni. A vinyl source egy douplex stream, ami hozzácsapja a fájlnevet, szóval csak simán át kell küldeni rajta, aztán a dest-hez adni. Azt nem néztem még, hogy pontosan a fájlnév hozzáadása hogyan történik, gondolom van valami konvenciójuk rá, lényegtelen.
gulp.task('js', function () {
return browserify({
entries: glob('./resources/assets/js/*.js'),
debug: true,
transform: [babelify]
})
.bundle()
.pipe(source('bundle.js'))
.pipe(gulp.dest('./public/assets/js'));
});A recipes-ben is amúgy valami ilyesmit használnak. [link]
Egyelőre még nem volt időm megnézni, mindjárt kipróbálom. Annyira nem vagyok elszállva babel-től, mint sokan. Valszeg nem fogom használni, inkább megvárom, amíg stabil lesz az async function. Azt írják, hogy draft jelenleg: [link], ami nekem nem elég.
Amúgy semmi gond nincs gulp-browserify-al, amíg kompatibilis gulp-al. Kösd meg, hogy 3.x-es gulp legyen a lib-ed függősége, mert azt írják, csak azzal kompatibilis. Valszeg a 4.0-s gulp-al el fog törni.
Buliban hasznos! =]
-
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.
Buliban hasznos! =]
-
inf3rno
nagyúr
Egy jó ideje már jasmine-el tesztelek TDD-vel, újabban meg cucumber-el BDD-vel. Szerintem jasmine teljesen alkalmas munkára. Mocha-t is megpróbáltam annak idején, de nem sikerült elindítani sem... Most nem melózok egy ideje, biomérnök állást keresek, meguntam a programozást, mármint azt a részét, hogy tucat webshopokat kell php-ben programozni. Ki nem állhatom azt a nyelvet, elég volt belőle pár év.
Jövőre ha lesz egy kis szabadidőm labor mellett, akkor összeszórok egy cucumber+jasmine kombinációt, mert a mostani cucumber elég fapados, és csak annyira lenne szükség, hogy jasmine fölé építsünk egy speckó test loadert, ami a gherkin syntax-os scenario-kat lefordítja jasmine-re. Ezt azért pár hét alatt össze lehet hozni sztem. Elvileg talán még gherkin parser is van készen, csak össze kell tákolni a jasmine-el.
Közben sikerült összekombinálni jasmine+browserify+karma+gulp-ot. Még dolgozok rajta pár órát, aztán felteszek egy project templatet github-ra. Jó lenne még ilyen finomságokat, hogy sourcemap meg coverage meg ilyesmik is beletenni. Talán majd később. Ha fent van, akkor hozzácsapok egy babelify-t is külön branch-en aztán belinkelem.
Buliban hasznos! =]
-
PumpkinSeed
addikt
válasz inf3rno #5564 üzenetére
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.
"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Kán
-
inf3rno
nagyúr
Magával a nyelvvel csak annyi, hogy xarból nem lehet várat építeni. A PHP4 kb olyan volt, mint a js-ben a típusellenőrzés. Azóta rátákoltak a tetejére egy oop réteget, kb. ennyi történt. Ugyanúgy szinkron, nem lehet aszinkron kódot írni benne, sem többszálút. Általában aztán az van, hogy az ügyfél kiválasztja magának a legolcsóbb tárhelyet, megveszi, kattintgat párat joomlában, vagy hasonló CMS-ben, aztán rájön, hogy ehhez nem ért, és akkor fejlesszek neki PHP-ben LAMP-ra valamit, feléből mennyit engedek alapon. A másik lehetőség ugyanez, csak az első versenyző spagetti kódban már félig összegányolta mielőtt belezavarodott a saját kódjába, és feladta, és hát nekem már csak "alig valamit" kell lekódolni. Meguntam ezt az életérzést. Úgy döntöttem, hogy ez így nem vezet sehova. Inkább elméletben képzem magam addig könyvekből, amennyi nekem kell, DDD, BDD, REST, SOLID, meg hasonló betűszavak terén, aztán ezentúl csak saját projekteket csinálok, pénzt meg másból keresek. Ennyi a bajom az egésszel.
Itt a karmás [link]. Egyelőre nem találtam még olyat, amivel jasmine teszteket össze tudok kombinálni babel-el, más dolgom volt. A Jest elvileg jó rá, gyakorlatilag jobb szeretném megoldani először anélkül.
Buliban hasznos! =]
-
Zedz
addikt
válasz inf3rno #5567 üzenetére
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?
-
inf3rno
nagyúr
válasz PumpkinSeed #5566 üzenetére
Ha a VM nem játszik, akkor próbáld meg a docker-t. Az kevesebbet eszik, és ugyanazt tudja. (Még nem foglalkoztam vele, de mások nagyon ajánlják.)
Nekem a projekt mappa külön HDD-n van, az összes projektnek abban van a kódja egy-egy mappában. A felosztásnál nekem most bejön a forrás az src-be a build meg a dist-be, a build task-ek mennek a tasks-be, a tesztek meg a spec-be. A runnerek a project root-ban vannak. Nagyjából ennyi a történet. Ha csapat van, akkor még bejön a képbe a CI szerver, a kódokat ott kell integrálni, aztán tesztelni és release-elni. Ha nincs csapat, akkor én nem szoktam ilyesmivel foglalkozni, letesztelem itthon, aztán kitolom a release script-el. Egyedül a rollback hiánya, ami aggasztó ilyenkor, de magabiztos vagyok. Nem jellemző, hogy oprendszerbeli eltérések miatt bármi történne. Legalábbis webes fejlesztésben nagyon ritkán találkozok ilyesmivel legtöbbször mod rewrite meg env vars témában, asztalra meg mobilra nem fejlesztek (még), azoknál gondolom nagyon más a helyzet. Nálam kb ennyi a történet.
Én nem tudnám megszokni, hogy több oprendszert használok fejlesztésre. Most váltok majd linux-ra win7-ről, teszteltem egy csomót. De hogy ide-oda váltsak az oprendszerek között meg rebootoljak, amikor egy projekthez akarok nyúlni, az kizárt. Akkor már jobb a VM vagy a docker.
Buliban hasznos! =]
-
inf3rno
nagyúr
Persze egy ideje ismerkedek vele, tisztább, szárazabb érzés a PHP után. PHP kb olyan, mintha a fél karom hiányozna, mert a webszerver kezeli a thread-eket, meg csak szinkron kódot lehet írni vele. (Tudom, hogy van appszerver, meg nagyon próbálják pusholni páran az aszinkron PHP-t, de rajtuk kívül senki nem veszi komolyan.)
Azért a nodejs is gyerek még, nagyon kell neki, hogy stabil támogatás legyen az ES7 async function-ön. Így future-ökkel el lehet bohóckodni, de nem az igazi. Most próbálok egy object stream-hez hasonló belső üzenetküldőt csinálni aszinkron kódoláshoz. Meglátjuk hova jutok vele. Igazából már 1 éve elkezdtem hobbiból, aztán azóta már egyszer újraírtam, és most fogom másodszor is. Tisztul a dolog. Nem tudom mások hogy írnak keretrendszereket, de nekem mindig kell 2-3-4 újraírós ciklus, amitől egyre szebb meg egyszerűbb lesz a kód. Úgy néztem azért másoknál is jellemző, hogy teljesen újraírják őket, pl ext4 vagy nanomsg (ami zeromq2), symfony2, és így tovább. Nagyon ritka, hogy elsőre megtalálja a legjobb megoldást az ember.
Buliban hasznos! =]
-
inf3rno
nagyúr
C#-ot valszeg nem fogom, mert búcsút mondok a windows-nak. A java szimpi, de csak fél évet foglalkoztam vele, akkor se túl komolyan. Jobb szeretem a könnyű súlyú dolgokat. Majd talán kisebb asztali alkalmazásokat rakok össze java-ban. De elvileg már node-al is lehet ilyesmit. Az android még ami izgat.
[ Szerkesztve ]
Buliban hasznos! =]
-
Zedz
addikt
válasz inf3rno #5572 üzenetére
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?
-
inf3rno
nagyúr
Ja, mindenki azt használ.
Na összeszórtam babel-el is, nehéz szülés volt, mármint a nodejs jasmine teszt vele. [link] A végén úgy döntöttem, hogy becsomagolom browserify-al az egészet egy pack-ba, aztán úgy tesztelem. Próbáltam jest-el is, annak elvileg van preprocessor-a, ami babel-el átalakítja, de bugos. Facebook fejlesztők kontár munkája... Úh. azzal nem jött össze a dolog. Most megy, de kellene még bele egy source map, amit nem tudom, hogy fel tudok e építeni browserify+babelify+uglify kimenetéből. Talán ha minden összejön, akkor igen. A következő probléma meg az lesz, hogy hogyan alakítom át a jasmine hibaüzeneteit a bundle-ről valami épkézláb dologgá a sourcemap segítségével. Meglájuk. Még úgysem használtam sosem ilyesmit.
Buliban hasznos! =]
-
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. :-)
Buliban hasznos! =]
-
Bigyo13
őstag
Sziasztok! Nem tudom jó helyre írok-e, de nem nagyon értek a JavaScript íráshoz, ezért egy kis segítség kellene! A következő parancsot szeretném kiadni minden IE8 böngésző megnyitásakor a vodafone.hu oldalnak, hogy ne legyen a felső részben a Javaslat a böngésző váltásra!
Találtam erre beágyazandó parancsot tehát a következő szöveggel, ami talán jó lenne script-ben is:
function disable_browser_upgrade_warning() {
remove_meta_box( 'dashboard_browser_nag', 'dashboard', 'normal' );
}
add_action( 'wp_dashboard_setup', 'disable_browser_upgrade_warning' );Ezt nem tudom, hogy kell megírni, hogy működjön is, mert ugye én a vodafone oldalát szerkeszteni nem tudom, ahova ezt be lehetne ágyazni... ezért kellene megoldás pl. Java script paranccsal!
Vagy hogyan tudnám a vodafone által beágyazott Javascriptet, ezt a részt az oldaluk letöltése közben blokkolni:
</script> <![endif]--> <!--[if lte IE 8]> <div id="iewarning" style="display: none;"> <div class="iewCenter clearfix"> <div class="iewText"> <h2> Böngéssz kompromisszumok nélkül! </h2> <p> Az általad használt böngészőt nem támogatja az oldalunk, így annak bizonyos részeit nem tudod teljes értékűen használni. A maximális élmény érdekében kérjük, hogy frissítsd böngésződet, igényeidnek megfelelően. </p> </div> <div class="iewDownload"> <h2> Ajánlott böngészők </h2> <div class="ie"> <h3>Internet Explorer</h3> <a href="http://www.microsoft.com/hun/upgrade/"> > letöltöm </a> </div> <div class="ff"> <h3>Mozilla Firefox</h3> <a href="http://www.mozilla.com/hu/"> > letöltöm </a> </div> <div class="ch"> <h3>Google Chrome</h3> <a href="http://www.google.com/chrome?hl=hu"> > letöltöm </a> </div> </div> </div> </div> <![endif]--> <script type="text/javascript"
Köszönöm!
Samsung Galaxy S3/S5
-
PumpkinSeed
addikt
válasz inf3rno #5576 üzenetére
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.
[ Szerkesztve ]
"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Kán
-
Bigyo13
őstag
Az IE8 user javascript kezelését megtaláltam... már csak helyesen kellene megírni a scriptet
A cél, hogy a vodafone.hu oldalán ne töltse be a böngésző figyelmeztető részt felül az oldalon, valami ilyesmi paranccsal:
(function() {
remove_meta_box( 'dashboard_browser_nag', 'dashboard', 'normal' );
}
add_action( 'wp_dashboard_setup', 'disable_browser_upgrade_warning' );}
)();De valamit nem jól írtam vagy kihagytam, mert nem működik
Samsung Galaxy S3/S5
-
Bigyo13
őstag
Elnézést... Megtaláltam a vodafone.hu oldalán a forrásban a scriptet, amit közömbösíteni kellene egy user scripttel:
</script> <![endif]--> <!--[if lte IE 8]> <div id="iewarning"
Kérem segítsen valaki, hogy kell megírni a közömbösítő vagy kikapcsoló user scriptet! Köszönöm
Samsung Galaxy S3/S5
-
inf3rno
nagyúr
-
Bigyo13
őstag
Ahogy én látom a Trixie támogatja az IE8 user scripteket, sőt arra találták ki: Trixie 0.2.3
To operate it:
1.put your userscript in c:\Program Files (x86)\Bhelpuri\Trixie\Scripts\ folder (it contains some samples you can start with)
2.restart IE or go to "Tools" -> "Trixie Options" menu and click "Reload Scripts" button (no need to restart IE)Már be is integráltam az IE8 böngészőbe a telepítővel, előtte fel kellett rakni az XP SP3-ra a NETF 2.0 -át.. nekem nem volt fenn!
Már csak a megfelelő user script megírása hiányzik! Mivel be és ki tudom kapcsolni a többi Trixie scriptet is az eszközök menűből megnyíló Ablakban!
Másik böngésző nem megoldás nekem, mert sok oldalt nyomtatni szeretnék a vodafone oldaláról IE8 alatt és felül foglalja a helyet a figyelmeztető ablak a Vodafone lapon pl., hogy váltsak böngészőt... sajnos nem integráltak az oldalba X-et vagy Ok-t, hogy eltünjön!
Tudnál segíteni a megfelelő script megírásában?Samsung Galaxy S3/S5
-
inf3rno
nagyúr
válasz PumpkinSeed #5578 üzenetére
Találtam bug reportot, +1-ezzél rá, hátha hamarabb javíták. [link] Windows-on még csak pár hónapos a docker valszeg amiatt bugzik még. Fél év múlva már biztosan jobb lesz. Majd kipróbálom én is, hátha többre jutok, bár fogalmam sincs, hogy mire tudnám használni.
Buliban hasznos! =]
-
PumpkinSeed
addikt
válasz inf3rno #5584 üzenetére
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.
"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Kán
-
inf3rno
nagyúr
válasz PumpkinSeed #5585 üzenetére
Közben átgondoltam, hogy mire jó a Docker. Bár nem vagyok benne biztos, hogy tényleg így működik.
A docker elvileg egy mini oprendszer az aktuális oprendszer felett. Minden oprendszer fölé ugyanazt teszi fel. A programok ezen a standard interface-en keresztül kommunikálnak, és nem látják a tényleges oprendszert. Tehát ha csinálsz egy docker image-t, azt bármelyik oprendszerre feltelepítheted, amin ott van a docker. Ez nyilván azt hozza magával, hogy webfejlesztésre nagyon jó, asztali app fejlesztésre pocsék, mert manapság egyáltalán nem gyakori, hogy a felhasználó gépén fut a docker, kivéve, ha Linux-os hozzáértő emberről van szó. Nyűg külön telepíttetni olyan Win felhasználókkal, akik analfabéták a géphez, márpedig ha ilyen a célközönséged, akkor próbálod minimumra venni a next-ek számát is, nehogy valamit elállítsanak. A webfejlesztésnél azért lehet jó, mert nem kell szerver meg oprendszer kompatibilitást tesztelni, elég csak felszórni az imaget egy container-be, aztán megy. Ennyi. Asztalinál is ez lenne az előnye, valszeg ezért el is fog terjedni.
A VM egész máshogy működik, az eltérő oprendszereket szimulál, szóval azon tudod tesztelni, hogy eltérő oprendszerekkel hogyan működik az alkalmazásod. Az asztali fejlesztés annyiból rosszabb vele, mint a docker-el lenne, hogy több környezetre kell tesztelni, és többször megírni a kód egy részét. A java ezen segít valamennyit, kb ugyanazt csinálja, mint a docker, elfedi az eltéréseket. A webfejlesztés kb ugyanolyan, mint docker-el, annyi, hogy a szerver gépet szimulálod vele, így az oprendszered lehet valami tök más is, pl Linux szerver Windows oprendszer. Még annyi előnye van, hogy kimentheted az image-t, aztán megoszthatod a többi fejlesztővel, ha csapatban nyomulsz. Így szerver beállítások beli különbség, meg ilyesmi nem okoz majd konfliktusokat, feltéve ha fel tudod szórni a szerverre ugyanazt az imaget.
Van még a vagrant, elvileg azzal leírhatod, hogy az aktuális imaget hogyan hoztad létre, szóval hogy hogyan került ebbe az állapotba a virtuális géped vagy a docker container-ed. Elvileg mindkettőnél lehet menteni az image-t is futás közben, gyakorlatilag nem tudom, sosem használtam egyiket sem. A vagrant azért lehet jó, mert belenyúlhatsz a szoftvercsomagba és a beállításokba anélkül, hogy mindent kézzel kellene nulláról újratelepítened. Valami olyasmi ránézésre, mint egy verzió kezelő a futási környezetre.
Nekem ránézésre egyikre sincs most szükségem, de csapatban mindenképp hasznosnak tűnnek, ugyanígy asztalihoz is, ha több oprendszert akarsz támogatni.
Buliban hasznos! =]
-
PumpkinSeed
addikt
válasz inf3rno #5588 üzenetére
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.
"Akinek elég bátorsága és türelme van ahhoz, hogy egész életében a sötétségbe nézzen, elsőként fogja meglátni benne a fény felvillanását." - Kán
-
inf3rno
nagyúr
válasz PumpkinSeed #5589 üzenetére
Szerintem az igazi akkor lesz, ha a felhasználóknak is alap lesz, hogy fent van a gépén ugyanúgy, mint a java. Kicsit bele kellene reklámozni, de megéri, mert nem csak java-t lehetne így fejleszteni platformfüggetlenül, hanem bármit.
Ha valaki csodálkozna, hogy hogy jön ez ide, docker-en van már elég régóta nodejs is. [link]
[ Szerkesztve ]
Buliban hasznos! =]
-
inf3rno
nagyúr
Próbálkoztam sourcemaps-el, de nem nagyon lehet ráhúzni. Nekem legalábbis nem sikerült egyelőre. Te hogyan debuggolsz babellel? Én egyelőre sima browserify + ugify-al próbáltam sourcemaps-et a gulp-sourcemaps-el, de csak a bundle tartalmát látom firebug-ban, a forrás fájlokat nem, illetve hibánál a sor is a tömörített fájlra vonatkozik, szóval mindig 1. Így egyáltalán nem használható debug-ra. Még próbálkozom. Ha mégis összejönne, akkor megpróbálom babel-re is.
Láttam, hogy van karma-cucumber, szóval elvileg cucumber-el is lehetne tesztelni, nem muszáj a jasmine. Majd megpróbálom azt is, mert nekem a BDD szimpatikusabb, mint a szimpla TDD, amit jasmine jelenleg támogat. Furának tartom, hogy azt írják jasmine dokumentációban, hogy BDD keretrendszer, amikor köze nincsen hozzá.
[ Szerkesztve ]
Buliban hasznos! =]
-
inf3rno
nagyúr
Megértelek, a dev környezet kiépítésére sajnálom leginkább az időt. Inkább leülök olvasni, vagy kódolok, minthogy erre menjenek el napjaim. Nekem nem tűnik annyira szélesen támogatottnak ez a sourcemap dolog, de egyelőre még csak firefox-ban néztem meg, elképzelhető, hogy más böngészőkben jobb a helyzet. Az elvet sem pontosan tudom, ami mögötte van, pl hogy lehetséges e több fájlt és azok kódjait betenni egy sourcemap-be, az is kérdés. Jelenleg csak a babelhez meg a minifyolt változathoz kellene, máshoz nemigen, szóval meg tudnám oldani nélküle is. Amit idáig összetákoltam dev környezetnek karmával meg nodejs-el az egész jó, át fogok térni rá a projektjeimnél, fejlettebb, mint amit előtte toltam.
[ Szerkesztve ]
Buliban hasznos! =]
-
Zedz
addikt
válasz inf3rno #5596 üzenetére
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.
-
inf3rno
nagyúr
Szvsz a TDD nem advanced dolog, hanem alapvető, ha fejleszteni akarsz. Ha nem ismered, nagyjából arról szól, hogy először a tesztet írod, utána meg az implementációt, mindezt kis kód részletekben. Így a végére a kód nagyjához lesz automatizált teszted. Menet közben is hasznos, mert a hibák azonnal kiderülnek, és nem kell utánanyomoznod órákat debug-al, hogy hol hasal el a kód. Én már inkább a BDD fele hajlok, annál először szövegesen írod le, hogy mit akarsz, aztán azt fordítod át tesztekre. Így a teszteket bármikor kicserélheted, úgy, hogy a szöveg változatlan marad. Ez sokkal rugalmasabb, mint a TDD, pl ugyanazok alapján a leírások alapján egy csomót azonos képességű eltérő klienst tudsz fejleszteni, esetleg eltérő API-kat kipróbálni, és így tovább.
Buliban hasznos! =]
-
DNReNTi
őstag
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!but without you, my life is incomplete, my days are absolutely gray
-
inf3rno
nagyúr
válasz DNReNTi #5599 üzenetére
Van még egy rakás másik editor is [link] pl aloha egész jónak tűnik, CK sem rossz egyébként. Ezeknél legtöbbször ott szokott a gond kezdődni, amikor egyedi dolgokat akarsz beletenni valamilyen pluginnel. Ha semmi ilyesmi nem kell, akkor bármelyik jó. Ha később kell, akkor meg még mindig kicserélheted. Van itt directive alohára: [link] meg ck-ra is [link] [link]
[ Szerkesztve ]
Buliban hasznos! =]
Új hozzászólás Aktív témák
- Mindent megtudtunk az új Nokia 3210-ről
- Kerékpárosok, bringások ide!
- Milyen billentyűzetet vegyek?
- Képeken az egyik kameráját elvesztő Sony Xperia 10 VI
- nVidia tulajok OFF topikja
- Vezetékes FÜLhallgatók
- Léghűtés topik
- Érkezik Magyarországa az LG szuper dizájnos hordozható projektora
- World of Tanks - MMO
- Otthoni hálózat és internet megosztás
- További aktív témák...
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest