- Apple asztali gépek
- Milyen billentyűzetet vegyek?
- Milyen notebookot vegyek?
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Azonnali VGA-s kérdések órája
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- OLED TV topic
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- Fejhallgató erősítő és DAC topik
- Lítium-ion/Li-ion akkumulátorok
-
PROHARDVER!
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
-
#5616
Sk8erPeter
nagyúr
inf3rno
#5603
Sk8erPeter
nagyúr
válasz
inf3rno
#5603
üzenetére
"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)
) -
Jim-Y
veterán
válasz
inf3rno
#5613
üzenetére
"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.
-
-
Jim-Y
veterán
válasz
inf3rno
#5604
üzenetére
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.
-
#5602
Sk8erPeter
nagyúr
inf3rno
#5598
Sk8erPeter
nagyúr
válasz
inf3rno
#5598
üzenetére
"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). -
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. 
-
-
#5589
PumpkinSeed
addikt
inf3rno
#5588
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.
-
#5578
PumpkinSeed
addikt
inf3rno
#5576
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.
-
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? -
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?
-
#5566
PumpkinSeed
addikt
inf3rno
#5564
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.
-
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.
-
Zedz
addikt
-
Zedz
addikt
válasz
inf3rno
#5543
üzenetére
Ő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?
-
Jim-Y
veterán
válasz
inf3rno
#5483
üzenetére
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?
-
Jim-Y
veterán
válasz
inf3rno
#5481
üzenetére
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..
-
Jim-Y
veterán
válasz
inf3rno
#5479
üzenetére
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 :/ -
Jim-Y
veterán
válasz
inf3rno
#5475
üzenetére
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>
-
Jim-Y
veterán
válasz
inf3rno
#5471
üzenetére
Amugy hogy miert nem ugyanaz.
null == false vs. !null
null == false
=========1. http://www.ecma-international.org/ecma-262/5.1/#sec-11.9.3
If Type(y) is Boolean, return the result of the comparison x == ToNumber(y).2. assert(typeof null === 'object')
3.
If Type(x) is Object and Type(y) is either String or Number,
return the result of the comparison ToPrimitive(x) == y.4. ToPrimitive(null) http://www.ecma-international.org/ecma-262/5.1/#sec-9.1
-> Null The result equals the input argument (no conversion).5. http://www.ecma-international.org/ecma-262/5.1/#sec-11.9.3
10. Return false.!null
===1. !ToBoolean(null)
2. Boolean(null) -> false
3. !false -> true -
Jim-Y
veterán
válasz
inf3rno
#5472
üzenetére
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.
-
Jim-Y
veterán
válasz
inf3rno
#5471
üzenetére
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
-
Zedz
addikt
válasz
inf3rno
#5411
üzenetére
"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.
-
Karma
félisten
válasz
inf3rno
#5389
üzenetére
É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.
-
Karma
félisten
válasz
inf3rno
#5379
üzenetére
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.
-
dqdb
nagyúr
válasz
inf3rno
#5373
üzenetére
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?
-
dqdb
nagyúr
válasz
inf3rno
#5358
üzenetére
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
-
Zedz
addikt
válasz
inf3rno
#5338
üzenetére
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.
-
martonx
veterán
válasz
inf3rno
#5338
üzenetére
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ő. -
Karma
félisten
válasz
inf3rno
#5331
üzenetére
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.
![;]](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
Hirdetés
- ThinkPad T14 Gen1 14" FHD IPS Ryzen 5 PRO 4650U 16GB 256GB NVMe ujjlolv IR kam gar
- Gamer pc 1080p
- ThinkPad T490 14" FHD IPS i5-8365U 16GB 256GB NVMe magyar vbill IR kam gar
- Nintendo Switch oled sok extrával, játékkal
- Xbox Series X, újrapasztázva, tisztítva, dobozában, 6 hó teljeskörű gar., Bp-i üzletből eladó!
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest