Kickstart Your Project With INIT And Grunt
Munkafolyamat INIT-tel és Grunttal
■ 
Friss blogmarkok
- Web Akadálymentesítési Útmutató (WCAG) 2.1 – nyilvános munkaterv – Megjelent a WCAG (Web Akadálymentesítési Útmutató) 2.1 nyilvános munkaterv (0)
- MongoDB Apocalypse Is Here as Ransom Attacks Hit 10,000 Servers – Több tízezer védtelen MongoDB szerverre csaptak le hackerek (2)
- 12 Signs You’re Working in a Feature Factory – A cél nélküli funkciógyártás néhány tünete (0)
- Translatable, custom dates in Twig templates of Drupal 8 – Saját dátumok megjelenítése, fordíthatóan a Drupal 8 smink rétegével dolgozva (0)
- NativeScript – Cross-Platform Native Development with Javascript – Fejlesszünk natív mobilalkalmazást JavaScripttel (0)
- GitHub Security Update: Reused password attack – Érdemes bekapcsolni a kétfaktoros azonosítást, ha a GitHub jelszavunkat más oldalakon is újra felhasználtuk (17)
- UX Design könyv – Hogyan tervezz felhasználóbarát és szerethető alkalmazásokat? (0)
- Introducing unlimited private repositories – Megváltozik a GitHub díjszabása: minden előfizetéshez korlátlan számú privát repository jár (0)
- Drupal 8 Twig: add custom CSS classes to menus (based on menu name) – Saját elképzeléseink szerinti CSS osztályok (automatizált) hozzáadása a Drupal 8 menüihez (0)
Cikkajánló
- _subi_:
Bevezetés a Sphinx keresőmotor használatába 
Bártházi András:
Perl alapjai VII.- Fájlműveletek
Nagy Gusztáv:
Weblapok ergonómiája
Friss csiripek
Csiripek betöltése…
Aktív fórum témák
Új fórum témák
Archívum
| H | K | Sze | Cs | P | Szo | V |
|---|---|---|---|---|---|---|
| 25 | 26 | 27 | 28 | 29 | 30 | 1 |
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 | 29 |
| 30 | 31 | 1 | 2 | 3 | 4 | 5 |
Anselm Hannemann is freelance
Gondolom skálázható ~
Még nem jöttem rá, mit
Nyilván a sebességhez is van
A skálázhatóság azt jelenti,
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...
Tud valaki gyors választ
Ha jól látom mindnek célja, hogy valamilyen automatizált folyamatot futtasson...
A grunt (ha gonosz akarok
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)
Akkor elméletileg a grunt-tal
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...
Nem valószínű, hogy plugint
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.
Én most jasmine + karma-t
Van amúgy maven for php. Nem
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 :)
Mavenről érdemes annyit
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.
A mavent inkább platformként
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:
Nem teljesen értem :D Ha jól
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...
Majdnem, leszámítva, hogy a
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 :)).
Persze, vágom, hogy