ugrás a tartalomhoz

Kickstart Your Project With INIT And Grunt

janez · 2014. Feb. 23. (V), 17.18
Munkafolyamat INIT-tel és Grunttal
 
1

Anselm Hannemann is freelance

Hidvégi Gábor · 2014. Feb. 23. (V), 18.43
Anselm Hannemann is freelance Front-end Developer focusing on building scalable front-end code for websites
Mit jelent a skálázható front-end kód kifejezés?
2

Gondolom skálázható ~

MadBence · 2014. Feb. 23. (V), 19.25
Gondolom skálázható ~ karbantartható (moduláris felépítés, stb)
3

Még nem jöttem rá, mit

Hidvégi Gábor · 2014. Feb. 23. (V), 19.35
Még nem jöttem rá, mit jelenthet. Számomra a skálázhatóságnak a sebességhez van köze, erről is ír, de a website-ja szerint reszponzivitással is behatóan foglalkozik.
4

Nyilván a sebességhez is van

MadBence · 2014. Feb. 23. (V), 20.15
Persze, a sebességhez is van köze, front-enden pl a megfelelő DOM-manipulálással nagyon sokat lehet gyorsítani. Ehhez nyilván olyan kód kell, ami az ilyen optimalizációkat támogatja (pl a facebook React keretrendszere)
5

A skálázhatóság azt jelenti,

inf3rno · 2014. Feb. 24. (H), 16.16
A skálázhatóság azt jelenti, hogy könnyen bővíthető valami. wiki/Scalability

Tipikusan load scalability értelemben használjuk szerver oldalon, ami azt jelenti, hogy különösebb erőfeszítés nélkül csapható hozzá új gép a szerverhez azzal a céllal, hogy növelje az alkalmazás futási sebességét.

Ugyanezt a fogalmat talán fel lehet használni kliens oldalon is kicsit árnyaltabban. Jelentheti azt pl, hogy eltérő képességű gép eltérő tartalmat kap. Ez vonatkozhat sebességre pl: a HexGL kiírja, ha alacsony az FPS, vonatkozhat kijelző méretre, pl a youtube felajánlhat video felbontást kijelző mérettől függően, de vonatkozhat a platform képességeire is, pl ha van websocket, akkor megy a chat, ha nincs, akkor nem, stb...

Létezik még programozással kapcsolatban functional scalability, ami azt jelenti, hogy könnyen tudsz új feature-t hozzáadni az alkalmazásodhoz.

Ha a teljes web alkalmazást nézzük, akkor ez jelentheti azt, hogy ha hozzácsapunk egy új feature-t a szerverhez, akkor annak kevés hatása legyen a kliens-en futó kódra. Ha csak a front-end-re vetítve nézzük, akkor jelentheti azt, hogy ne legyen ismétlődés a kódban, legyen könnyen újrahasznosítható, legyen szétvágva modulokra, stb...

Nehéz megmondani, hogy pontosan mire gondolt a srác, gondolom ez valami új hype lehet, amit a HR-esek használnak állashirdetésekben, és onnan vette át, vagy passz. Google legalábbis nekem nem dobott semmi használhatót ezzel kapcsolatban...
6

Tud valaki gyors választ

inf3rno · 2014. Feb. 25. (K), 23.37
Tud valaki gyors választ adni, hogy mi a különbség a grunt, INIT, yeoman generator, travis ci, maven között?

Ha jól látom mindnek célja, hogy valamilyen automatizált folyamatot futtasson...
7

A grunt (ha gonosz akarok

MadBence · 2014. Feb. 26. (Sze), 00.23
A grunt (ha gonosz akarok lenni) egy felturbózott make. Kismilló plugin van hozzá, leginkább olyan feladatokra szokás alkalmazni, mint automatikus js minifikálás, buildelés. Egyébként van egy hasonló rendszer, a Gulp, ami nekem sokkal szimpatikusabb.

Az INIT-et bevallom őszintén, nem ismerem.

A yeoman mindenféle projectekhez tud alap vázat generálni, megspórol az embernek egy csomó időt (nem kell boilerplate kódot írni).

Travis CI (ahogy a neve is mutatja) egy continous intergration szolgáltatás, ami github projectek automatikus tesztelését végzi, különböző konfigurációk mellett (pl lefuttatja a teszteket 0.6, 0.8, 0.10, 0.11-es node.js alatt), de egy csomó minden másra is használható, én pl használtam már docpad publikálásra is (aki esetleg bővebben olvasna róla, rövidke írás róla)

A maven pedig egy build tool és dependency manager egyben (leginkább java környezetben találkozhat vele az ember)
8

Akkor elméletileg a grunt-tal

inf3rno · 2014. Feb. 26. (Sze), 00.26
Akkor elméletileg a grunt-tal ugyanúgy lehet automatikusan vezérelni build-et és unit teszteket, mint a mavennel és a travis-el, csak meg kell írni hozzá a plugineket?

Egyébként van egy hasonló rendszer, a Gulp, ami nekem sokkal szimpatikusabb.

Nem vagy egyedül, nekem is szimpatikusabb a baromi nagy konfig fájlok helyett inkább kód formájában megadni, hogy mit akarok...

Találtam jó pár cikket a témában:


Azt hiszem áttérek a require.js-ről és a grunt tanulgatásáról a browserify és gulp kombinációra, sokkal ígéretesebb...
9

Nem valószínű, hogy plugint

MadBence · 2014. Feb. 26. (Sze), 00.45
Nem valószínű, hogy plugint kell hozzá írni (valaki már biztos megírta). Unit tesztek futtatásához pl nem is feltétlenül kell grunt, hiszen azok célszerűen valami egyszerű paranccsal lefuttathatóak ,a keretrendszertől függ. Én pl tipikusan mocha/should kombót használok, amit a mocha -w test/* folyamatosan futtat a háttérben automatikusan, minden fájlmódosítás után.
A travis sem találja ki hogy mik a unit tesztek, itt pl az npm-mel futtatom a teszteket.
10

Én most jasmine + karma-t

inf3rno · 2014. Feb. 26. (Sze), 01.20
Én most jasmine + karma-t használok kliens oldalon, ott is van autowatch, mondjuk jobb szeretem, ha ctrl+t-re van bindelve a dolog az IDE-ben, de ez már tök más téma... A grunt nekem eléggé overengineeringnek tűnik a gulp-hoz képest.
11

Van amúgy maven for php. Nem

BlaZe · 2014. Feb. 26. (Sze), 22.24
Van amúgy maven for php. Nem használtam, érdekes lehet annak, akinek eddig pont ez hiányzott az életéből.

Mavenről érdemes annyit tudni, hogy okos és sok jó dolgot tud, de - főleg egy nagyobb project esetében - nem érdemes úgy nekiállni, hogy nincs házon belül maven szaki, mert nem jól használva meg tud fojtani egy projectet. Viczián Istvánnak van egy jó bevezetője, illetve cikksorozata róla.

Verhás Péter pedig írt egy Gradle/Ant/Maven bejegyzést, csak hogy még egy cucc előkerüljön :)
12

Mavenről érdemes annyit

inf3rno · 2014. Feb. 27. (Cs), 00.40
Mavenről érdemes annyit tudni, hogy okos és sok jó dolgot tud


Tudnál egy kis ízelítőt írni. Nekem elég lenne felsorolás szintjén pár mondatban... Elég sok időt töltöttem azzal az utóbbi 1-2 évben, hogy keretrendszereket kerestem és értékeltem különböző témakörökben. Szívesen hozzácsapnám ezt is a listámhoz.
13

A mavent inkább platformként

BlaZe · 2014. Feb. 27. (Cs), 02.11
A mavent inkább platformként érdemes felfogni, mint keretrendszerként. Ha erre építesz, akkor gyakorlatilag az egész alkalmazás életciklust át fogja/tudja fogni. A projectek/modulok összefogásától és viszonyaiknak leírásától kezdve a fordításon, tesztelésen, release készítésén, és nem utolsósorban a függőségek kezelésében, meg persze még kismillió dologban. Nagyon jól integrálható CI serverekbe (jenkins, bamboo pl), így egy jól összerakott maven configgal csomó mindent meg tudsz csinálni pár gombnyomással is akár. Nálunk pl úgy néz ki a release, hogy localban elbrancheljük a mastert, majd bambooban rábökünk az adott komponens adott release branchének a release planjén a run planre. Innentől kezdve mindent automatikusan csinál, fordít, teszteket futtat, majd készít rpm-et, jarokat, zipeket, verziót léptet és tagel gitben, feltolja az egészet nexusba és innentől gyakorlatilag használható, telepíthető. Mindez egy, vagy több xml fileban van definiálva, viszonylag kényelmes módon. Ugyanígy készül a config, db stb release is.

Mivel kezeli a függőségeket, egy ügyesebb CI server automatikusan le tudja futtatni modulok, projectek buildjét, ha új build készült valamiből, amitől azok függnek stb. Az egyes lifecycle phase-ek egymásra épülnek, tehát pl a package alapesetben nem fog megtörténni, ha törnek a tesztek, vagy nem fordul a kód, így a build standardizálása mellett segíti a stabilitást, minőséget (tud pl mindenféle static code analyzert futtatni) is.

Okos dolog még benne a profil, mi ezzel oldjuk meg, hogy a performance tesztek, vagy rpm készítés ne fusson a fejlesztő gépén, bambooból indítva viszont igen.

A nehézsége a fentiekből adódóan az, hogy mivel elég komplex tud lenni, eléggé el lehet tolni, ha valaki nem ért hozzá megfelelő mélységben, és könnyen át tud csapni gányolásba.

Apache-ék egyébként ezt mondják a maven céljairól:
  • Making the build process easy
  • Providing a uniform build system
  • Providing quality project information
  • Providing guidelines for best practices development
  • Allowing transparent migration to new features
14

Nem teljesen értem :D Ha jól

inf3rno · 2014. Feb. 27. (Cs), 04.18
Nem teljesen értem :D Ha jól sejtem, akkor van mindenkinek gitje és van egy közös repo, ahova felszórjátok a változásokat. Gondolom teszteltek helyileg is, úgyhogy biztosan van egy maven helyben, ami buildel meg tesztel (már ha olyan nyelvről van szó, amit buildelni kell). Utána ha minden okés, akkor felszórjátok a közös repora a változásokat, amivel kapcsolatban van a CI szerver, aztán megmondjátok a CI szervernek, hogy csináljon új releaset, és ő elkezd dolgozni, buildel, tesztel mint állat, és kiköpi, hogy készen van az új release, amit aztán feltol a production szerverre. Valahogy így megy?

Btw master branch változást lehet figyeltetni git hookkal, úgyhogy talán még azt a run-ra kattintást is meg lehet spórolni, bár nem vagyok benne biztos, hogy jól értem a folyamatot...
15

Majdnem, leszámítva, hogy a

BlaZe · 2014. Feb. 27. (Cs), 23.38
Majdnem, leszámítva, hogy a production szerverre nem CI teszi ki az alkalmazásokat, mert bár kényelmes, de kevesebb kontrollt ad. Prodon az ilyet azért nem szeretjük :) A CI nexusba tolja fel az előállt artifactokat, ahonnan aztán maven, meg egyéb toolok le tudják tölteni.

Git hookkal a sima build megy, a releasere értelemszerűen nekünk kell rányomni. A kettő között az a különbség, hogy előbbi snapshot release-t csinál, a másik pedig rendes release-t, ami aztán kimegy qa, uat, demo, prod rendszerekre.

Összességében jó cucc, és jól is működik, de egy ekkora infrastruktúrának az összerakása egyrészt idő, másrészt karban is kell tartani... :) A CI-t igazából azért hoztam csak szóba, mert a maven egy ilyen megoldásnak tökjó alapot nyújt. De nem ez a kimondott lényege (bár gondolom ez nem újdonság :)).
16

Persze, vágom, hogy

inf3rno · 2014. Feb. 28. (P), 00.49
Persze, vágom, hogy erőfeszítés, de komolyabb projektnél csapatban gondolom mindenképp megéri.