CoderGirls

Tailwind CSS: azonnali stílus, végtelen rugalmasság

Tailwind CSS: azonnali stílus, végtelen rugalmasság

Ismerd meg a Tailwind előnyeit.(max 10 p olvasási idő)

A modern webfejlesztés világában egyre többen keresik azokat a megoldásokat, melyek gyorsabb és hatékonyabb munkavégzést tesznek lehetővé. Ebben a cikkben részletesen elemzem a Tailwind CSS keretrendszert, hogy mindenki mélyrehatóan megismerhesse, nem csupán a felszínét érintve. Megvizsgálom, hogy milyen előnyöket kínál a Tailwind a többi keretrendszerrel szemben, mint például a Bootstrap, és hogyan válhat elengedhetetlen eszközzé a fejlesztők számára.

 bstw.jpg

Miért válasszuk a Tailwind CSS-t?

A Tailwind CSS egy utility-first keretrendszer, ami azt jelenti, hogy a stíluslapok helyett utility osztályokat használunk az elemek stílusozásához. A "utility-first" keretrendszer, mint a Tailwind CSS, olyan megközelítést alkalmaz a webfejlesztésben, ahol a stílusok alkalmazását úgynevezett "utility osztályok" segítségével végzik. Ezek az osztályok kis, újrafelhasználható CSS szabályokat tartalmaznak, amelyek egyetlen stílusfunkciót vagy tulajdonságot hajtanak végre. Például lehet egy osztály, ami csak a szöveg színét állítja be, egy másik, ami a margót szabályozza, és így tovább.

Az ilyen utility osztályok lehetővé teszik a fejlesztők számára, hogy gyorsan és hatékonyan alkalmazzanak stílusokat közvetlenül az HTML elemeiken keresztül, anélkül, hogy saját CSS stíluslapokat kellene írniuk minden egyes stílusmódosításhoz. Ez a megközelítés jelentősen növeli a fejlesztési sebességet és rugalmasságot, mivel a fejlesztők összeállíthatják a kívánt megjelenést a különböző utility osztályok kombinálásával, mindezt anélkül, hogy bonyolult és hosszú CSS szabályokat kellene kezelniük.

Gyakran ajánlom, hogy amennyiben újrafelhasználható HTML elemeket vagy komponenseket hozunk létre, érdemes azokat a Tailwind osztályokat, amelyeket egyébként közvetlenül az HTML elemekhez rendelnénk, külön CSS osztályokba szervezni. Ennek előnye, hogy később a CSS-ben könnyebben lehet módosításokat végezni. Azok az esetek, amikor nincs szükség saját osztály létrehozására, a Tailwind osztályokat közvetlenül az HTML-be illeszthetjük. Az általam használt terminológiában ezeket a direkt az elrendezéshez kapcsolódó osztályokat "layout osztályoknak" hívom, míg az újrafelhasználhatókat "komponens osztályoknak" nevezem.

Képzeljük el, hogy egy weboldalon dolgozunk, ahol van egy gomb, amit több helyen is használunk, és egy fő tartalmi terület, aminek az elrendezése specifikus csak egy adott oldalra. Itt láthatunk egy példát arra, mikor használjunk "layout osztályt" és mikor "komponens osztályt".

Példa Layout Osztályokra

(Tailwind CSS osztályokkal közvetlenül):

Ez egy layout osztály használatának példája, ahol közvetlenül az HTML elemre alkalmazunk Tailwind CSS osztályokat az oldal fő tartalmi területének elrendezéséhez. Itt nem hozunk létre újrafelhasználható komponenst, csak az adott oldal elrendezését állítjuk be.

Példa Komponens Osztályra

(Működni fog az npm használatával, vagy egyszerűen csak localhoston az  @apply, a codepen ezt sajnos nem tudja külön css-ben értelmezni.)

Az előző példában a button elemet ellátjuk egy btn-primary osztállyal, amely örökli a .bg-teal-500, .text-white és további osztályok stílusait. Amikor a CSS fájl generálódik, létrejön egy .btn-primary osztály, amely azonos tulajdonság-érték párokat tartalmaz, mintha ezeket manuálisan adtuk volna meg CSS-ben, például { background-color: teal; color: white; }.

Na de mi is ez az @apply @layer, prefix? Új szintű rugalmasság:

A Tailwind egyedi @layer, @apply direktívái és a konfigurálható színek, betűtípusok támogatása révén lehetővé teszi a fejlesztők számára, hogy precízen szabályozzák az alkalmazásuk stílusát. Ezzel szemben a Bootstrap gyakran korlátozottabbnak bizonyul, mivel nem engedélyezi alapból az egyedi beállításokat a prefix utáni értékekkel.

A Tailwind CSS számos prefixet kínál (mint a bg-,text-, font-, px-,py-, my-, w-, h-, stb.) , amelyek segítségével finomíthatjuk a stílusok alkalmazását különböző körülmények között. 

  1. Class prefixes: a Tailwind CSS számos osztály prefixet kínál, amelyek segítségével gyorsan és egyszerűen alkalmazhatunk stílusokat HTML elemekre. Itt van néhány alapvető és gyakran használt prefix, valamint azok rövid magyarázata:
    1. bg-: a háttérszín beállításához. Például: bg-blue-500 egy közepes árnyalatú kék háttérszínt alkalmaz.

    2. text-: a szöveg színének megadásához. Például: text-gray-700 egy sötét szürke szövegszínt alkalmaz.

    3. font-: abetűtípus súlyának (vastagságának) és stílusának beállításához. Például: font-bold félkövér betűtípust alkalmaz, font-italic dőlt betűtípust.

    4. px- és py-: a padding (belső margó) beállításához vízszintesen (px-) és függőlegesen (py-). Például: px-4 vízszintes belső margót ad, py-2 függőleges belső margót.

    5. my- és mx-: a margin (külső margó) beállításához függőlegesen (my-) és vízszintesen (mx-). Például: my-5 függőleges külső margót ad, mx-3 vízszintes külső margót.

    6. w-: az elem szélességének beállításához. Például: w-1/2 az elemet a szülő szélességének 50%-ára állítja.

    7. h-: az elem magasságának beállításához. Például: h-full az elemet a szülő magasságának teljes méretére állítja.

    8. border-: a keret (border) vastagságának, stílusának és színének beállításához. Például: border, border-2, border-red-500.

    9. rounded-: az elem sarkainak lekerekítéséhez. Például: rounded enyhe lekerekítést alkalmaz, rounded-lg nagyobb lekerekítést.

    10. flex-, grid-: a Flexbox és Grid elrendezési rendszerekhez kapcsolódó osztályok. Például: flex, flex-row, grid, grid-cols-3.

      Ezek a prefixek a Tailwind CSS magját képezik, lehetővé téve a fejlesztők számára, hogy gyorsan és hatékonyan alkalmazzanak stílusokat anélkül, hogy közvetlenül CSS-t kellene írniuk.

      ill. a Tailwind CSS lehetőséget biztosít arra, hogy egyedi értékeket adj meg a különböző stílusokhoz az úgynevezett "arbitrary values" (tetszőleges értékek) használatával. Ez azt jelenti, hogy ha a Tailwind által előre definiált értékek nem felelnek meg a projekt specifikus igényeinek, akkor közvetlenül az osztálynevekben specifikálhatod a kívánt értékeket. Ezt úgy teheted meg, hogy az osztály nevéhez hozzáadod a kívánt értéket szögletes zárójelek között.

      Például:
      mt-[18.5rem]: Egyedi felső margót ad meg, ebben az esetben 18.5 rem magasságút.
      left-[20%]: Az elemet a szülő konténeréhez képest 20%-ban balra helyezi.

      Ez a funkció rendkívül rugalmassá teszi a Tailwind CSS-t, lehetővé téve a fejlesztők számára, hogy pontosan szabályozhassák az elemek méretét, pozícióját és egyéb stílusbeli aspektusait anélkül, hogy el kellene hagyniuk a keretrendszert vagy külön CSS szabályokat kellene írniuk.

      Az egyedi értékek használata nem csak a méretekre és pozíciókra korlátozódik; szinte bármilyen Tailwind osztályhoz használhatod őket, például színekhez, árnyékokhoz, betűméretekhez stb., hogy pontosan illeszkedjenek a designod specifikus követelményeihez.

  2. Responsive prefixes: ezek lehetővé teszik, hogy stílusokat alkalmazzunk különböző képernyőméretekhez. Például: sm:, md:, lg:, xl:, 2xl: stb. Az sm:bg-red-500 például csak a sm (small) méretű és annál nagyobb képernyőkön alkalmazza a piros háttérszínt.
  3. Pseudo-class prefixes: ezekkel állíthatók be a stílusok a különböző állapotokban (pl. hover, focus). Például: hover:, focus:, active:, disabled:. Az hover:bg-blue-500 a kék háttérszínt csak egérmutatóval való fölé hovereléskor alkalmazza.
  4. Dark mode prefix: a dark: prefix segítségével sötét módban különböző stílusokat alkalmazhatunk. Például: dark:bg-gray-800 a háttérszínt csak sötét módban állítja szürkére.
  5. Group-hover prefix: a csoporton belüli elemekre alkalmazható hover stílusokhoz. A .group osztállyal jelölt szülő elemen belüli group-hover: prefix segítségével alkalmazott stílusok csak akkor aktíválódnak, amikor a felhasználó az egész csoport felett hoverel. Például: group-hover:text-white.

  6. Focus within prefix: a focus-within: prefix segítségével olyan stílusokat alkalmazhatunk, amelyek akkor aktíválódnak, ha a szülő elem vagy annak bármelyik gyerekelemére fókuszálunk. Például: focus-within:ring.
  7. First-child, last-child, odd-child, even-child prefixes: ezek a prefixek segítségével specifikus stílusokat alkalmazhatunk az elemekre azok pozíciójától függően a szülőjükön belül. Például: first:, last:, odd:, even:. Az first:font-bold az első gyerekelem szövegét teszi félkövérré.

@Layer direktívák

Az @layer direktíva a Tailwind CSS-ben lehetővé teszi, hogy strukturáltabban és hatékonyabban szervezd a saját stílusaidat, különösen, amikor a Tailwind segédosztályaival kiegészítve saját CSS osztályokat hozol létre. Az @layer direktíva használatának néhány előnye:

  1. Szervezettség: a @layer direktíva segít szervezetten tartani a CSS-edet, lehetővé téve, hogy különböző rétegekbe (pl. alapértékek, komponensek, segédosztályok [base, components, utilities]) rendezd a kódodat. Ez megkönnyíti a projekt stílusainak kezelését, mivel pontosan tudod, hol található minden egyes definíció.
  2. Hatékonyabb CSS generálás: a Tailwind a build folyamat során intelligensen optimalizálja a végső CSS fájlt. Amikor a saját stílusaidat egy adott rétegbe (pl. components) sorolod, a Tailwind jobban tudja kezelni a CSS kimenetet, például csökkentve a redundanciát és elősegítve, hogy a generált stíluslapok kisebbek és gyorsabban betölthetőek legyenek.
  3. Könnyebb testreszabás:@layer használatával könnyebben testreszabhatod a Tailwind előre definiált stílusait, anélkül, hogy befolyásolnád az eredeti stílusokat. Ez nagyobb kontrollt ad a fejlesztőknek a stílusok fölött, lehetővé téve, hogy saját komponenseket hozzanak létre anélkül, hogy összeütközésbe kerülnének a Tailwind alapértelmezéseivel.
  4. Jobb teljesítmény és prioritás:@layer direktíva segít biztosítani, hogy a saját stílusaid megfelelő prioritást kapjanak a CSS cascade-ben. Azáltal, hogy explicit módon jelölted a komponensek rétegét, csökkented az esélyét annak, hogy a Tailwind segédosztályai felülírják a saját stílusaidat, különösen, ha konfliktusok merülnének fel a CSS szelektorok specificitása miatt.
  5. Ill ami még nagy előny, hogy az ebben írt custom style-od nem fog belekerülni a végső (build-elt) CSS fájlba, amíg azt nem használod fel valahol a HTML-ben. 

@layer components

A @layer components használata egy strukturált megközelítés a CSS írásához a Tailwind CSS keretrendszerben, amely javítja a kód szervezettségét, optimalizálja a build folyamatot, megkönnyíti a testreszabást, és javítja a teljesítményt. Ez a réteg a felhasználói felület komponenseinek stílusait tartalmazza. Ide tartoznak a gombok, formok, kártyák stílusai és bármely egyéb összetett UI elem, amit újra szeretnél használni a projektben.

@layer base

Az @layer base réteg az alapvető stílusokat tartalmazza, amelyek általában az alap HTML elemekhez kapcsolódnak, mint például a <body>, <h1> - <h6>, <p> stb. Ez a réteg jó hely az alapértelmezett stílusok felülírására vagy új alap stílusok bevezetésére. 

Pl. hozzunk létre egy egyedi typo.css fájlt az alapvető tipográfiai stílusok meghatározására a @layer base használatával, és a címsorok (h1-h6) definiálása a @layer utilities rétegben. Ez egy érdekes megközelítés, amely lehetővé teszi a stílusok moduláris kezelését és a kód újrafelhasználhatóságának növelését. Azonban fontos megjegyezni, hogy a címsorokat (h1-h6) általában nem helyezzük az @layer utilities rétegbe, mivel ezek az elemek inkább az alapértelmezett tipográfiai stílushoz tartoznak, nem pedig újrafelhasználható segédosztályokhoz. Mindenesetre, bemutatom, hogyan nézhet ki a két megközelítés, ha mégis így szeretném használni. 

typo.css az alap tipográfiai stílusokhoz (@layer base): 
Ebben a fájlban definiálhatod az alapvető HTML elemek, mint például p, a, strong stílusait, valamint a h1-h6 címsorok alapértelmezett stílusait is. 

Újrafelhasználható címsor stílusok (@layer utilities): 
Bár a címsorok (h1-h6) tipikusan nem kerülnek a utilities rétegbe, ha mégis úgy döntenél, hogy egyedi segédosztályokat hozol létre ezeknek az elemeknek a stílusához az újrafelhasználhatóság érdekében, így tehetnéd meg:



@layer utilities

Az @layer utilities réteg a segédosztályokat tartalmazza, amelyek általában specifikusabb, egyedi felhasználásra szánt stílusmódosításokat tesznek lehetővé. Ebben a rétegben definiálhatod saját utility osztályaidat, vagy finomíthatod a Tailwind beépített utility osztályait, mintha a keretrendszer részét képeznék. Ez azt jelenti, hogy ezeket az egyedi segédosztályokat ugyanúgy használhatod az @apply direktívával a CSS-ben, vagy közvetlenül a HTML elemeiden, mint a Tailwind beépített osztályait. Kb. mintha fejlesztő lennél a Tailwind-nél és kiegészítenéd az osztályait a sajátoddal amit utána ugyanúgy tudsz használni @apply-ban hiba nélkül vagy a html-ben vagy prefix-ek után. Nézzünk néhány példát arra, hogyan hozhatsz létre és használhatsz egyedi utility osztályokat a Tailwind projektben. 


1. Egyedi segédosztály létrehozása

Tegyük fel, hogy szeretnénk egy flex-center osztályt létrehozni, amely gyorsan középre igazítja az elemeket flexbox használatával, mind vízszintesen, mind függőlegesen. Először hozd létre az osztályt az @layer utilities blokkon belül:

Ezután a flex-center osztályt közvetlenül használhatod a HTML elemeiden, hogy gyorsan létrehozz egy középre igazított layoutot.

Majd integrálás az @apply direktívával
Az egyedi flex-center osztályt az @apply direktívával is integrálhatod más stílusdefiníciókba, hogy összetettebb komponenseket hozz létre. Ebben a példában létrehoztunk egy .card osztályt, amely alkalmazza a flex-center osztályunkat, ezzel egy középre igazított kártya layoutot hozva létre, amely több más Tailwind segédosztályt is használ. Érted már mennyire király a Tailwind? Annyi testreszabhatóságot ad, hogy kb. a határ a csillagos ég. :) 

A CSS komponens alapú felhasználása (Vue, Svelte, React ...) 

A Tailwind CSS komponensalapú keretrendszerekkel (mint Vue, Svelte, React stb.) való használatakor célszerű lehet a globális stílusokat, mint például komponens specifikus stílusokat, a projekt központi CSS fájljában (main.css vagy hasonló pl card.css) definiálni az @layer direktívával. Ez lehetővé teszi, hogy a stílusaidat modularizált és karbantartható módon kezeld. Max SPA fejlesztésnél használj scope style-ban a komponensen belül @apply-al saját class-okat. 

Függvények Tailwind-ben: miért hasznos a theme(), screen() függvényről is tudni?

A theme() függvény használata különösen előnyös lehet, amikor közvetlen hozzáférést szeretnél a Tailwind konfigurációs fájlban (tailwind.config.js) definiált értékekhez, hogy dinamikusan alkalmazd őket a projektben, különösen olyan helyzetekben, ahol az @apply direktíva által nyújtott segédosztályok nem elég rugalmasak vagy nem fedik le a szükséges eseteket.

Finomhangolás: a theme() függvény lehetővé teszi, hogy közvetlenül a Tailwind konfigurációból származó értékeket használj, finomhangolva a stílusaidat.
Dinamikus Stílusok: dinamikus stílusokat hozhatsz létre, amelyek reagálnak a felhasználói interakciókra, mint például a hover állapot.

A screen() funkció lehetővé teszi, hogy a médialekérdezéseidet a töréspontjaid neveivel hivatkozz, ahelyett hogy azok értékeit megismételnéd a saját CSS-edben. @media screen(sm) { /* ... */ } Ez a kód a fordítási időben feloldódik az alapul szolgáló képernyő értékre, létrehozva egy szabályos médialekérdezést, amely megfelel a megadott töréspontnak ami min-with: 640px. Ezeket a töréspontokat a tailwind.config.js-ben előre megadhatod. 

A screen() funkció és az sm: előtag közötti választás függ a használt technológiától és a projekt specifikus igényeitől. Mindkettő a reszponzív design megvalósítását célozza, de eltérő módon működnek. 

Dark mode engedélyezése

A Dark mode, vagy sötét mód, egy olyan funkció, amely lehetővé teszi a weboldalak számára, hogy automatikusan vagy felhasználói beállítás alapján sötétebb színpalettára váltsanak, ami kímélőbb a szemnek különösen alacsony fényviszonyok között. Tailwind CSS-ben a Dark mode támogatás beépített, és egyszerűen használható.

Először is, győződj meg róla, hogy a konfigurációs fájlod (tailwind.config.js) engedélyezi a Dark Mode-ot. Ehhez a darkMode opciót állítsd class vagy media értékre. A media használata esetén a rendszer a felhasználó rendszerének preferenciáit fogja követni, míg a class módban manuálisan kell kezelned a dark mode osztály hozzáadását a HTML elemhez.

// tailwind.config.js module.exports = { darkMode: 'media', // vagy 'class' // további konfigurációk... };

Tegyük fel, hogy egy egyszerű gombot szeretnél stílusozni, amelynek a háttere és a szöveg színe megváltozik Dark Mode-ban. 

<button class="bg-white text-black dark:bg-black dark:text-white"> Text </button>


Ebben a példában a bg-white text-black osztályok határozzák meg a gomb alapértelmezett, világos módú stílusát, míg a dark:bg-black dark:text-white osztályok a sötét módban alkalmazandó stílusokat adják meg.

Ha a darkMode opciót class-ra állítottad, akkor kézzel kell hozzáadnod a dark osztályt a <body> taghez vagy a szülő elemhez, hogy aktiváld a sötét módot. Például:

`<body class="dark">
   <button class="bg-white text-black dark:bg-black dark:text-white"> Text </button>
</body>`

Ha a media opciót használod, akkor a sötét mód automatikusan aktiválódik a felhasználó rendszerének preferenciája alapján, és nincs szükség a dark osztály manuális hozzáadására.

Viszont létezik talán még ettől jobb opció is, amit talán kevesen ismernek és amit egy weboldalnál használtam és bevált. 

Miért lehet jobb a tw-colors lib ehhez?

A tw-colors egy npm csomag, amely további színkezelési lehetőségeket kínál Tailwind CSS projektekhez. Ez a csomag segíthet abban, hogy finomabban szabályozd a színpalettát, beleértve a világos és sötét módot is, lehetővé téve a fejlesztők számára, hogy egyszerűbben kezeljék a színek átmeneteit és variációit a különböző felhasználói preferenciák alapján.

Mivel közvetlenül a Tailwind CSS-hez tervezték, a tw-colors könnyen integrálható meglévő projektekbe, minimalizálva a konfigurációs erőfeszítéseket és megkönnyítve a fejlesztők számára, hogy kiaknázzák a kiterjesztett színkezelési lehetőségeket anélkül, hogy alapjaiban kellene módosítaniuk a projekt struktúráját.

Hogyan használható?
A tw-colors csomag telepítése egyszerű npm vagy yarn parancs segítségével történik, és a Tailwind CSS konfigurációs fájljába való integrálása után azonnal elérhetővé válnak a továbbfejlesztett színkezelési lehetőségek. Például: npm install tw-colors v. yarn add tw-colors

Telepítés után be kell állítanod a színeket a tailwind.config.js fájlban, ahogy azt a csomag dokumentációja részletezi.


Pár szót a Bootstrap CSS keretrendszerről 

A Bootstrap egy népszerű front-end keretrendszer, amelyet a gyors prototípuskészítés és a reszponzív weboldalak fejlesztése érdekében hoztak létre. Bár számos előnnyel rendelkezik, mint például a könnyű használat és a széles körű komponenskönyvtár, vannak bizonyos hátrányai is, különösen a személyre szabhatóság és a rugalmasság terén.

Korlátozott személyre szabhatóság

A Bootstrap előre meghatározott stílusokkal és komponensekkel rendelkezik, amelyeket a Bootstrap csapata tervezett. Bár ezek a komponensek gyorsan integrálhatók és használhatók, gyakran nem illeszkednek tökéletesen egy adott projekt vizuális identitásához. Ennek eredményeképpen a fejlesztők gyakran kényszerülnek az alapértelmezett stílusok felülírására, hogy megfeleljenek a tervezési követelményeknek. 

Ez a folyamat időigényes lehet, különösen, ha sok komponenst kell módosítani. Emellett a felülírások kezelése bonyolulttá válhat, ami nagyobb CSS fájlokat eredményezhet, és nehezítheti a kód karbantartását.

A Utility-First megközelítés hiánya

A Bootstrap nem követi a utility-first megközelítést, ami ellentétben áll a Tailwind CSS és hasonló keretrendszerek filozófiájával. A utility-first megközelítés lehetővé teszi a fejlesztők számára, hogy gyorsan alkalmazzák a szükséges stílusokat direkt módon, az elemekhez hozzáadott segédosztályok használatával. Ez a módszer nagyobb rugalmasságot biztosít és leegyszerűsíti a dinamikus UI elemek kezelését.

A Bootstrap használatakor a fejlesztők gyakran támaszkodnak a keretrendszer által biztosított komponensekre és osztályokra, ami korlátozza a rugalmasságot, különösen bonyolultabb vagy egyedi felhasználói felületek kialakításakor.

Ha pl szeretnék egy egyedi button class-t deklarálni akkor elég bonyolult változóneveket kellene megjegyeznem, ill amivel felül írhatom a BS alap button osztályát az is bonyolultabb egy TW-től.  

screenshot-getbootstrap_com-2024_03_02-00_03_10.png
A BS 5-ös verziójában max annyi könnyedség lett, hogy betették minden komponens végére (maradjunk az előbbi példánál, a gomboknál) a BS alap variable scss komponensét kiválogatva csak a gombokra vonatkozókat. Régen ezeket magunknak kellett kb felkutatni az ömlesztett scss/_variables.scss fájlban.

screenshot-getbootstrap_com-2024_03_02-00_08_43.png


Ez a fajta könnyedség és rugalmasság főként azok számára válik nyilvánvalóvá, akik mélyebben elmerültek a Bootstrap használatában az npm segítségével, ellentétben azokkal, akik az egyszerűbb, CDN-alapú beillesztési módszert részesítik előnyben. Az utóbbi megközelítés gyakran vezet ahhoz, hogy a fejlesztők !important direktívák segítségével próbálják felülbírálni a stílusokat, ami messze nem ideális és gyakran okoz fejfájást a kódbázis karbantartása során. Ez a gyakorlat komoly kihívásokat állíthat a projekt skálázhatósága és karbantarthatósága szempontjából, és gyakran vezet a kód minőségének romlásához. :S 

Mivel a Bootstrap egy teljes keretrendszer sok komponenssel és stílussal, a nem használt CSS szabályok könnyen "megduzzaszthatják" a projektet, még akkor is, ha a fejlesztő csak néhány komponenst használ a keretrendszerből. Ez ellentétben áll a modern webfejlesztési best practices-ekkel, amelyek a lehető legkisebb fájlméretre és a gyors betöltési időkre összpontosítanak.

Lezárás: 

A Tailwind "Core Concepts" szekciója alapos betekintést nyújt a keretrendszer alapelveibe, bemutatva, hogyan lehet az @apply direktívát, a theme() függvényt, és más kulcsfontosságú funkciókat használni a stílusok testreszabásához.

Továbbá, a "Layout" szekció segítségével felfedezhetjük a Tailwind által kínált előre definiált színeket, osztályokat, és egyéb hasznos eszközöket, amelyek felgyorsítják a fejlesztési folyamatot, miközben elegendő szabadságot biztosítanak az egyedi dizájn kialakításához. Bár a Tailwind nem kínál olyan előre kész megoldásokat, mint például a Bootstrap komponensei, ez a megközelítés szándékosan támogatja a design személyre szabását és kreativitást, nem szorítva a fejlesztőket felesleges korlátok közé.

Remélhetőleg ez az írás segít jobban megérteni a Tailwind CSS-t és annak előnyeit, sőt, talán meg is szeretteti ezt a keretrendszert azokkal, akik korábban esetleg vonakodtak tőle. A Tailwind CSS kínálta szabadság és kontroll egyedülálló lehetőséget biztosít a fejlesztők számára, hogy pontosan olyan weboldalakat hozzanak létre, amilyeneket csak szeretnének, anélkül, hogy bármilyen előre meghatározott design mintához kellene alkalmazkodniuk.

A Tailwind CSS tehát nem csak egy eszköz a gyors prototípus készítéshez, hanem egy olyan keretrendszer, amely támogatja a kreativitást és lehetővé teszi a fejlesztők számára, hogy valóban egyedi és lenyűgöző weboldalakat alkossanak.

Úgy gondolom, hogy a kreativitás azt jelenti, hogy bátorságot adunk magunknak, hogy a dolgokat másképp lássuk és új utakat fedezzünk fel.

Ha eddig eljutottál olvasásban, akkor köszönöm. Ha tetszett a cikk hagyj egy kommentet, vagy oszd meg olyan emberekkel, akiket szintén érdekelhet a téma. Üdv. egy Frontend lány.  

Tailwind CSS: azonnali stílus, végtelen rugalmasság Tovább
Béta-v.0: React app létrehozása Node.js backenddel - Útikalauz a fejemben

Béta-v.0: React app létrehozása Node.js backenddel - Útikalauz a fejemben

reavt_node.jpg
A - béta v - cikkekben olyan bemutatása lesz a React és egyéb technológiáknak, melyekben elmondom én hogyan kezdtem el tanulni a React-ot pl. Azon felül hogy vettem egy kurzust Udemy-n vagy kaptam vagy 8 könyvet, ami nagyon sok hasznos dolgot takar, már a kezdeti fázisban be vagyok zsongva hogy alkossak is valamit. Először arra gondoltam hogy backend nélkül hozok létre egy sima kis portfolió site-ot, de annak nem sok értelmét látom Reactban csak simán, szóval emiatt megspékelem kis izgalommal is és a blogom kezdem el megírni. 


Ez az cikk arra szolgál, bemutassa a bénázásaim, hogy ne érezd azt, hogy mindenki úgy kezdi, hogy mindent tud egyből. Mivel kezdő vagyok a React és Node-ban is, emiatt az összes problémát le fogom írni, és azt is hogy mire kerestem rá, hol akadtam el, hogyan oldottam meg. Nem egy nap alatt fog megszületni a cikk, mivel nem egy napos tanulás eredményét irom majd le. 

Először is gágel a barátom, és rákerestem arra hogy: How to create a React App with a backend (A How to keresések elég fontosak, hogy jól tudjunk keresni neten), amire sok találat között próbáltam olyan platformot választani amiről már sokat hallottam jó értelemben. A freecodecamp-en nyitottam meg egy útmutatót mely elsőre hasznosnak bizonyul. Én az a fajta ember vagyok aki jobban szereti az olvasott tutorialokat, szakmai doksikat, mint a videókat. Ahogy építem az appot, mellette úgy írom a cikket egyből. A cikkben angolul írom azokat a kifejezéseket, amiket alapból angolul használunk magyar szóhasználatban is, ha ezekre nem tudod a válaszokat nézz utána, ezzel is fejlesztve az angol szakmai tudásod. 

Eszközök amikre szükségem lesz a freecodecamp szerint: 

  1. Meg kell győzödnöm arról hogy van npm a gépemen, (erre egy biztos igen a válaszom, hiszen napi szinten használom a munkaim során, de végigmegyek ezeken is hátha valakinek ez is hasznos). Az "Ninja Pumpkin Mutants", vagy most éppen "Noxious Plant Miasma" az egy package manager, amit csomagok kezelésére használunk. (ezeket a neveket a npmjs.com logó fölötti fejlélcében olvashatod. :D ❤ ) 

    Az open source fejlesztők mindenhonnan használják az npmj.com-ot csomagok megosztására és kölcsönzésére, és sok cég használja az npm-et a privát fejlesztések kezelésére is. Maga az npm pedig egy javascript package manager Node JavaScript platform számára, npm install után szervezetten node_modules mappában megtalálhatóak a csomagok melyeknél a függőségeket (dependency) a node inteligenssen kezeli. Általában ezek közül a parancsok (commanc cli) közül hármat használunk leggyakrabban, npm init, npm install vagy az npm uninstall.

    Használata:

    Ha pl. akarjuk kezelni ezeket a függőségeket a projektünkben, akkor letrehoztuk ugye a projekt mappát, majd terminálba bemegyünk a mappa gyökerébe (cd project_name) majd nyomunk egy npm init-et, ezzel inicializáljuk (beindítjuk). Ez a háttérben egy exec műveletté alakul, sok kérdés megválaszolásával lértehoz egy package.json file-t, ami egy JSON-fájl, amely a Javascript/Node-projekt gyökerében található. A projektre vonatkozó metaadatokat tárolja, és a projekt függőségei, szkriptjei, verziói és még sok más kezelésére használják. Ezután az npm install  kiadásával lehúzzuk a projektünkbe ezt a csomagot, aminek a saját doksijában megtaláljuk az npm-re vonatkozó configurációs beállításokat. 

  2. Kell egy code editor, IDE, én ez esetben a VSCode-ot használom, amit a cikk is ajánl nekem. 
  3. Meg kell győzödnöm arról hogy van GIT a gépemre telepítve, ez is pipa. Ha nem használtad még a GIT-et soha, akkor először azt nézd át mire jó neked.  Ez szükséges lesz később az alkalmazásunk Herokuval (A Heroku egy felhőplatform, amely lehetővé teszi a számunkra, hogy alkalmazásokat építsünk, kihelyezzük az APP-unkat) való üzembe helyezéséhez. (deploy), és a kódunk verziókövetéséhez. 
  4. És kell egy heroku account hogy később a segítségével teljesen ingyenesen közzétehessem az alkalmazásom. (ezt pillanatok alatt létrehoztam)

1. lépés: Létrehozom a Node (Express) backend-et

A gépem LINUX ubuntu, verziószáma: Ubuntu 22.04 LTS. (de Mac-en és Win-en is terminált használok, csak ott a git bash-t szoktam) Emiatt is, meg alapból is a terminál műveleteket preferálom, mert nekem gyorsabb parancsokat megtanulni, mint emlékezni hova kell kattintgatni GUI felületeken. A gépemen van egy work mappa azon belül létrehoztam két mappát, mkdir react_projects és azon belul mkdir coder_blog amiben a konkrét kód lesz. A coder_blog gyökerében a terminálba kiadom az npm init -y parancsot ami ugyanaz mint a sima init annyi különbséggel hogy ez egyből létrehozza a package.json fájlt. Majd nyomok egy code . - ot, ami megnyitja a vscoe-ot ott ahol kiadtuk ezt a parancsot, ez esetben az egész coder_blog mappát. 

  • Létrehoztam egy mappát server néven, és ebbe elhelyezek egy index.js fájlt. 
  • Express.js segítségével lérte kell hoznom egy webszervert, ami majd a 3001-es porton fog futni. 
// server/index.js

const express = require("express");

const PORT = process.env.PORT || 3001;

const app = express();

app.listen(PORT, () => {
  console.log(`Server listening on ${PORT}`);
});
  • Installálom az express-t az npi i expess paranccsal. Ezzel létrejön egy node_modules mappa, és egy package.lock.json fájl automatikusan generálva, ami részletesebben mutatja a csomag függőségeit, verzióját, frissítéseit. 
  • Ezután a gyökér mappán belül a package.json-ralesz szükségünk, amibe létree kell hoznom a script-et amivel el tudom indítani a webszervert lokálisan. A script neve npm start lesz és a test helyére kerül a "script"-be. 
// server/package.json

...
"scripts": {
  "start": "node server/index.js"
},
...

clip-1.gif

  •  Ha lefutattom az npm start scriptet  a terminálban akkor ezt az üzenetet kell kapnom: 
npm start

> node server/index.js

Server listening on 3001

2. lépés: API végpont létrehozása

  • a Node és Express-t API-ként hasznéljuk majd.  Az alábbi kód végpontot hoz létre az /api útvonalhoz, amit az app.listen fuction elé helyezünk
// server/index.js
...

app.get("/api", (req, res) => {
  res.json({ message: "Hello from server!" });
});

app.listen(PORT, () => {
  console.log(`Server listening on ${PORT}`);
});

 Ha valamit változtatunk a kódunkban,akkor ujra kell indítanunk a szervert. Ctrl + C és újra npm run start. 

Ezután írjuk be ezt az útvonalat a bongészőbe: http://localhost:3001/api és meg is kapjuk az üzenetet: {"message":"Hello from server!"}. 


3. lépés Hozzuk létre a frontend-et React-al. 

Ez az a rész ahol sok időt fogok tölteni, az-az amíg nem lesz meg a teljes frontend, nem megyek át a backendre. Annyi hogy az alapokat felépítem az alapján amit a freecodecamp is ír és valami kezdeti fázisu miniprojektet deployolok majd. 

  • Nyitok egy másik tab-ot a terminálba (CTRL + SHIFT + T) majd beirom ezt a parancsot 
    npx create-react-app client
  • Ezzel létrehoztam egy client névvel ellátott React projektet, minden függőséggel együtt. Ennek a package.json fájljába hozzá kell adunk egy proxy tulajdonságot a script-ek után, ami a hálózati kérésekért felel, tudatjuk az appunkkal hogy a szerverünk melyik porton fut. 
client/package.json

...
"proxy": "http://localhost:3001",
...

Ezután beleléptem a client mappába a terminálban (cd client) és futtatom a react start scriptet (npm run start) ami elindítja a localis feluletet ahol a frontend fut, ez esetben a 3000-es port. 

screenshot_from_2022-08-19_14-12-13.png

 screenshot_from_2022-08-19_14-20-59.png

4. lépés: HTTP-kéréseket  kell küldenem a React appból a szervernek az /api végpont használatával, amit már korábban létrehoztam

Ehhez az src mappában található App.js komponenshez lépek, és HTTP kérést küldök a useEffect Hook használatával. (magyar). Magyarul talán úgy lehetne írni ezt hogy hatásokat kezelő objektum A useEffect hook. Esetünkben a data lesz egy hatás. 

A Fetch API használatával egyszerű GET-kérést küldök a backend-nek, majd az adatokat JSON-ként küldjük vissza. Ezt az adatot egy data változóba tároljuk el. 

Ez lehetővé teszi, hogy az üzenetet megjelenítsük oldalunkon, ha van. A JSX-ünkben egy feltételt használunk, hogy ha még nincsenek meg az adataink, akkor írjuk ki a „Loading...” szöveget.

  • Átírom a // client/src/App.js fájlt.  és megjelenítem a {"message":"Hello from server!"} üzenetet. 
// client/src/App.js

import React from "react";
import logo from "./logo.svg";
import "./App.css";

function App() {
  const [data, setData] = React.useState(null);

  React.useEffect(() => {
    fetch("/api")
      .then((res) => res.json())
      .then((data) => setData(data.message));
  }, []);

  return (
    <section className="App">
      <header className="App-header">
        <img src={logo} className="App-logo" alt="logo" />
        <p>{!data ? "Loading..." : data}</p>
      </header>
    </section>
  );
}

export default App;

clip-4.gif

screenshot_from_2022-08-19_15-42-13.png
A useState Hook-al eltároljuk a data állapotát (állapotváltozó deklarálás), A változónkat data-nak hívják, de nevezhetnénk akárminek. A useState segítségével sikerül „megőrizni” bizonyos értékeket a függvényhívások között – egy új módja annak, hogy pontosan ugyanazokat a képességeket használjuk, amelyeket a this.state biztosít egy osztályban. Általában a változók „eltűnnek”, amikor a függvény kilép, de az állapotváltozókat a React megőrzi.A belső állapot egy React app elég fontos része. Ha a komponensen belül meghívjuk ezt a useState-et, az vissza fog térni egy két elemű tömbbel. A tömb első eleme az aktuális állapotot tartalmazza, a második eleme pedig egy function, amit ha meghívunk és beleteszünk értéket azzal  beállítjuk a következő állapotot. Ezt szokás array destructuring-el két változóba bekötni, hogy könnyebb legyen rájuk referálni. (const [data, setData] = React.useState(null);) Lehetőség van inicializálni a belső állapotot, a useStat functionba értéket bedobni. Ami az én kódomban a null. 
 
Ezeket az alapokat a Reacthoz egy udemy képzésen tanulom én is - React - The Complete Guide (incl Hooks, React Router, Redux)  Ezt még én szerencsére olcsóbban vettem, ha kell valakinek szivesen megadom a belépőm és tudja nézni igyenesen is, persze csak ha már én végeztem vele. Mert mutatja hogy hol járok. ill. volt már pár kisebb Reactos feladatom melóban, ami inkább max javítás volt, szóval láttam már Reactos komponenseket etc. de ez a freecodecamp-es anyag elég jól leir mindent, mint ahogy én most ezt magyarul is. egyelőre ennek az utasításait követem. Ha nem így lett volna már első lépésként git-be tettem volna a projektet mert így szoktam meg. Ill. van egy magyar programozó akinek figyelemmel kísérem a munkait pár éve és van egy kurzus oldala ahol szintén van react kurzus. 

folyt. köv.

Béta-v.0: React app létrehozása Node.js backenddel - Útikalauz a fejemben Tovább
A portfólió oldalak szerepe, jelentősége programozóknál - első munkahely

A portfólió oldalak szerepe, jelentősége programozóknál - első munkahely

Egy jó weboldal nem csak önmagáért van, hanem illeszkednie kell a stratégiánkba, hogy elérjük a célunkat.

Férfi, három számítógép előtt ül: Photo by olia danilevich from Pexels

A portfólió avagy referencia oldalak célja minden szakmában az, hogy bemutassa munkáinkat, tanulmányainkat, digitális önéletrajz is valamilyen szinten. De vajon szükség van-e erre ahhoz, hogy több ügyfelünk, avagy jobb munkahelyünk legyen? Egy junior fejlesztőnek mindenképpen szükséges? Senior programozóknak és fentebbi szinten ez elhagyható?


IT szintek: junior vs pályakezdő, első munkahely portfólió oldal nélkül

Ahhoz, hogy ezt a témakört jobban szétszedjük, meg kell ismerkednünk alapvető IT szintekkel programozási, fejlesztői területen belül, ill. azt mi alapján szerezzük meg az első munkahelyet.

Az első munkahely sikeres felvételije után juniorok leszünk, vagy pályakezdők, vagy gyakornokok.

Van az a pályakezdő autodidakta, akinek soha nem volt még állása az IT piacon belül, akinek gyakorlati helye sem volt, hiszen nem volt egyetemista és van az, aki egyetem alatt már dolgozott valahol részmunkaidőben (gyakornokként), ezáltal tapasztalatot szerezve könnyebben véve az akadályokat a munkaerőpiacon.

Amikor kikerülnek egyetemről azok a tanulók, akik már előtte dolgoztak valahol gyakorlati időszakban sikeres felvételt nyerhetnek junior fejlesztői állásra, mentorált környezetben.

Akik pedig autodidakta módon érték el mindezt a konnektivizmus (hálózatalapú tanulás) adta lehetőségekből adódóan, hozzájuthatnak egy kezdő munkahelyhez, őket hívjuk pályakezdő fejlesztőknek. Olyan esetben, lehet itt is gyakornoki munka, ha valamilyen képzés után felajánlanak nekünk egy tanulói fizetést a munkánkért cserébe.

Ez a különbség abból adódik, hogy az egyetemisták jó esetben több évet végigtanultak keményen, több technológiát és nyelvet mélyebben érintettek, mint az aki önállóan ezt egy fél év alatt kb. felszedte magára. Én is autodidakta módon tanultam meg nagyon sokmindent. mivel az informatikai OKJ-t ezelőtt 10 évvel végeztem, így újrakezdőnek számítottam, emiatt én is éreztem bizonyos feladatoknál ezeket a különbségeket a bőrömön.

Persze ezek is tanulható dolgok, de mennyivel jobb lett volna, ha az egyetem már ad egy olyan alapot, amivel ezek a feladatok is könnyebben áthidalhatóak már a junior vagy trainee korszakban.

Első munkahely: Photo by Startup Stock Photos from Pexels

Első munkahely

Fentebb már írtam, hogy egyetemistáknak viszonylag könnyebb a munkába állás, hiszen a gyakorlati hely sokat dob az első igazi munkahelyük megtalálása felé. De mi van azokkal akik autodidakta módon tanultak? Nekik jobban el kell tudni adni magukat, és megmutatni mit tudnak. Viszont mindkét kezdő ágnak szüksége lesz alapvető dolgokra a munkaerő piacra lépésnél, már tanulási fázisban is.

Elengedhetetlen eszközök, információáramlás

Mielőtt elkezdenénk munkahelyet keresni szükségünk lesz:

  • egy jól összerakott CV-re és motivációs levélre, elég sokféle ingyenes önéletrajz készítő netes weboldal van már én a CV-template-et szoktam használni.
  • egy GitHub profilra, ahol az általunk készített weboldalak, programok kódjai megtekinthetőek
  • sok sok motivációra, amikre én azt szoktam ajánlani hogy hozzunk létre pl egy CodePen profilt, és oda készítsünk szemléletes gyakorló feladatokat, amiket mások előtt fel merünk vállalni, amikre büszkék is lehetünk. Avagy építsünk saját márkát, vagy készítsünk, tanuljunk olyan dolgokat amikkel könnyebbé tehetjük a napjainkat.
  • LinkedIn profil, mivel ez is egyfajta digitális önéletrajz, amit a cégek, HR-esek szeretnek átnézni. Eleinte, ez jó ha minden releváns munkahellyel ki van töltve és tanulmányokkal, de később úgyis a mások által (akikkel együtt dolgoztunk) adott értékelések fognak számítani és a pontozások.
  • kapcsolatok, szakmai mentor, ezeknek a megszerzését, akár programozói csoportokba is megtehetjük, vagy szakmai esteken, meetup-okon.
  • legalább egy erős alapszíntű angol tudásra, hiszen az angol az a közös nyelv amit minden programozónak ismernie kell. Ezáltal megérthetjük külföldiek kódjait is. Ill. sok szakmai anyag, ami naprakész, ill. dokumentáció angolul van jelen az interneten.
  • egy szépen összerakott portfólió oldal, melyen megismerhetnek téged, a készségeid, a referenciáid, hiszen szebben mutat, ha itt van egyben összeszedve és nem e-mail-ben küldözgetjük a linkek halmazát a leendő munkáltatónak.
A suszter és a cipője

A portfolió oldalak digitális lenyomatok arról, kik vagyunk, mivel foglalkozunk, amolyan netes önéletrajz, tudjuk hogy kellene, de a tudás vagy a munka még jobban kellene, és emiatt ez mindig csusztatva van, vagy el sem készül egyáltalán, mert mire lenne időnk erre, addigra meg már nincs szükség rá. Nem elengedhetetlen része a jó munka megtalálásának, de az egy plusz pont ha ez is megvan. Meg ez kb. olyan, mint a suszter meg a cipője esete.

Ki ne ismerné a mondást, amely szerint a suszter cipője mindig lyukas? Ez bizony nem csak a suszterekre, de ránk is igaz! Na nem mintha az általunk elkészített cipőkkel lenne a gond, hisz néha szerencsétlenségünk vagy szerencsénk, annyi megrendelést, munkát kell teljesíteni, hogy pont a saját weboldalunk karbantartására, elkészítésére, nem marad időnk. Viszont egy jó, fancy technológiával kódolt oldal, melyet teljes egészében mi készítettünk el, nagyon jó belépő lehet az üzleti világba, munkahelyekre.

Medior, mid-senior, senior, architect szint

Hogy ki számít mediornak, seniornak stb., ez nem csak az évek függvénye és nem csak a tudásé, mert van olyan senior aki egyik munkahelyen már architect-nek számítana, másikon meg senior lenne, vagy erős medior. Nem feltétlen van szerződésbe leírva, hogy junior programozó, vagy trainee programozó csak annyi, hogy szoftverfejlesztő, vagy programozó. Ezek a szintek KKV szektorban eléggé elmosódnak, multiknál pedig nem mindig egyértelmű, ki miért medior vagy junior.

Önéletrajz: Photo by cottonbro from Pexels
Minek a portfólió oldal? MInek az önéletrajz?

Több seniort és architect-et kérdeztünk meg, szerintük felesleges a portfólió oldal de még a CV is, hiszen ott a LinkedIn profil, akkor minek kérnek magyar-angol CV-t? Ebben egyetértek velük, szerintem is felesleges még egy doksi, de ezt még itthon nem engedték el a munkáltatók. Úgy néz ki mindig ragaszkodunk valamihez, ami a múltunkhoz kapcsolhat kicsit minket. Pedig a mai digitalizálásban, ez ma már szerintem is elhagyható lehetne. Sokaknak nincs is CV-je se, mert nem hajlandó erre időt pocsékolni. Vannak referenciáik, és Github profiljuk, amit szívesen eküldenek, ill. már itt a munkaváltás legtöbbször ajánlás útján megy.

Vállalkozási létben, fontosabb már a weboldali jelenlét, de itt is sok az ajánlás általi munka és ha sok a megrendelés, nincs mindig idő a sajátunkra.

Referencia oldalak, nem csak fejlesztőknek

Ma már sokféle weboldal létezik. Az első legfontosabb, hogy eldöntsük, nekünk mire van szükségünk, mit szeretnénk ténylegesen a weboldallal elérni.

Az ingyenes megoldásoktól kezdve milliós nagyságrendig kaphatunk ajánlatokat. Nem mindegy, hogy csak bemutatjuk a termékünket, szolgáltatásunkat vagy egy webshop-ot készíttetünk. Arra se árt rákérdeznünk, hogy keresőoptimalizálásra technikailag előkészített oldalt kapunk-e vagy teljesen kész keresőoptimalizált oldalt. Ilyen esetekben nem árt szétnézni a fejlesztő portfólió oldalán.

Látogassuk meg az általa készített referenciaként felsorolt oldalakat és teszteljük le telefonnal, tablettel, laptopon, ill. bizonyos kereső vagy kulcsszavakra behozza-e az adott oldalt a Google keresője.

Egy jó weboldal nem csak önmagáért van, hanem illeszkednie kell a stratégiánkba, hogy elérjük a célunkat.

Te mit gondolsz a portfólió weboldalak jelentőségéről?

Eredeti megjelenés itt: letscode.hu

A portfólió oldalak szerepe, jelentősége programozóknál - első munkahely Tovább
Informatika, webfejlesztés és webdesign magánórák és csoportos órák pályakezdőknek, és junioroknak :)

Informatika, webfejlesztés és webdesign magánórák és csoportos órák pályakezdőknek, és junioroknak :)

Ha úgy érzed segítségre lenne szükséged a szakdolgozatodnál, esetleg iránymutatás is elég lenne, avagy pályakezdő vagy és nem tudod miben mennyit kellene tanulni, keress meg bátran. :)

 

tutor.jpg

Ha úgy érzed segítségre lenne szükséged a szakdolgozatodnál, esetleg iránymutatás is elég lenne, avagy pályakezdő vagy és nem tudod miben mennyit kellene tanulni, keress meg bátran. :)

Nettó 5500 ft / óra (60 perc) a tanítás nálam, ez lehet több is, attól függően mi a feladat. Számlát adok erről is.

Alapvetően nem meggazdagodni akarok ebből, hanem segíteni, ezt néha ingyen is megteszem, de azt vettem észre, hogy ami ingyen van az komolytalan, nem veszik komolyan annyira a házikat, vagy a tanulást, emiatt is hoztam meg azt a döntést, hogy szinte ingyen vállalok néha órákat magán és csoportosan. 4 nél több emberrel nem foglalkozok egyszerre.

Rólam annyit kell tudni, hogy majdnem medior szinten vagyok tudásban, ez nyilván megoszlik attól függően milyen nyelvről beszélünk, de frontend vonalon mindenképp segiteni tudok, ill pályatanácsadást is, ami nem kerül pénzbe nálam. :)

Amikkel rendelkezem
- Ifjuságszociológia, Tanulás metodika képzés - Egyetemi képzés (FSZ)
- Pedagogus asszisztens OKJ (dolgoztam egy évet helyettesítő tanárként suliban, és korrepetáltam kollégiumban)
- Informatikai érettségi
- Szoftverüzemeltető webfejlesztő OKJ
- Javascript alapok - Egyetemi tanfolyam
- Udemy kurzosok
- Frontend fejlesztő oklevél
- ECDL excel oklevél
- Webdesign alapok oklevél (majd később önmagamat képeztem Figmában pl, UI-ban és UX-ben is...)
- Középfokú angol nyelvismeret írásban és szóban (folyékonyan beszélek viszonylag, ezt fél évet tanultam magamtól munka mellett)

Nyelvek, eszközök: HTML5, CSS3, Js, jQuery, Alpine.js, npm, Tailwind, Bootstrap, Flexbox, etc. ...

Ha úgy érzed szükséged lenne rám, keress meg privát üzenetben facebookon, és érdeklődj a kapacitásomról.

Informatika, webfejlesztés és webdesign magánórák és csoportos órák pályakezdőknek, és junioroknak :) Tovább
Animations with Alpine

Animations with Alpine

Here is your training guide on adding simple animations to your Alpine transitions.

animations-with-alpine1.jpg

Alpine gives you the ability to implement simple javascript functionality in your application without pulling in a larger library like Vue or React. Some use-cases for using alpine are modal pop-ups or simple drop-downs. And luckily, creating some simple transition animations with Alpine is super easy and fun!

 

No Animation

First, let's take a look at a simple Alpine dropdown without animation.

 

When we click on the Open Dropdown button from the CodePen above, you can see that the ul element gets toggled. It will show and hide without any animation.

Simple Animation

Adding an animation to your Alpine components is as simple as changing x-show="open" to x-show.transition="open". Take a look at this example below.

 

You can now see that if we click on the Open Dropdown button, it has some nice fade and scale animations.

social.jpg

Simple Animation Origin

What if instead, we wanted to change origin, where it's scaling in from. Well we could simply chain the .origin to our x-show attribute, like this: x-show.transition.origin.top.left="open", and you'll get the following:

CHECKOUT OUR LATEST PRODUCT - THE ULTIMATE TAILWINDCSS PAGE CREATOR �

 

Now, you can see that when you click the Open Dropdown button, our animation scales in from the top left. We could customize our animation even more by chaining more functionality to that attribute. Learn more about all the options you have available in the Alpine Readme.

Animations with Tailwind

Next, we may want to add even more flexibility to our animations by including Tailwinds Transition classes. We can leverage some new Alpine attributes that will allow our component to add/remove transition classes during the animation. Take a look at the following example:

 

As you can see, the animation is very similar to the previous examples; however, we are using Tailwind classes to handle our transitions. Before you understand all of the Alpine transition attributes, it's good to remember that there are 2 phases during an animation.

  1. The Enter Phase - When the element is displayed
  2. The Leave Phase - When the element is no longer displayed

Each of these phases have 3 attributes. Here are the Enter phase attributes:

  • x-transition:enter="" - Added during the entire enter phase

  • **x-transition:enter-start="" - Added before the element is inserted and removed one frame after inserted

  • x-transition:enter-end="" - Added one frame after element is inserted (same time the previous enter-start is removed), removed when transition animation finishes.

Here are the Leave phase attributes:

  • x-transition:leave="" - Added during the entire leave phase

  • x-transition:leave-start="" - Added immediately when the leaving transition is triggered and removed one frame after the trigger.

  • x-transition:leave-end="" - Added one frame after leaving transition is triggered (same time the previous leave-start is removed), this is then removed when the animation is complete.

Make sure to learn these attributes and start playing around with them to get better at adding animations to your Alpine components.

Conclusion

Be sure to visit the Alpine repo and give it a start if you have not already.

Adding transitions and animations to your HTML elements used to take a decent amount of work, but now thanks to Alpine and Tailwind we can create some cool animations and transitions as the elements get displayed on our page.

Animations with Alpine Tovább
6 Fun Things You Can Do With Just CSS

6 Fun Things You Can Do With Just CSS

Build a simple photoshop & pie-charts with few lines of CSS.

1_gds9yomon7wwzjgbwj3byw.png

Love it or hate it, CSS(Cascading Style Sheets) is the language we use to style the HTML elements.

While there are some fabulous preprocessors like SCSS(that get compiled into CSS eventually) and offer more features than normal CSS, this does not mean that you can’t do amazing things by just using plain, standard CSS.

CSS has 520 distinct and while you may not need to know more than 30 or 50 properties, exploring the uncommon CSS properties can surely help you achieve more with just your stylesheets.

Below are 6 amazing things you can do with just CSS:

1. Create Portraits & Add Effects

Source: plainenglish.io . Photo by Albert Dera on Unsplash

The above effect is created just by using the background-clip property of CSS.

p{
background-size: 70vh;
background-position: center;
line-height: 16px;
background: url("photo.png");
-webkit-background-clip: text;
background-attachment: fixed;
background-clip:text;
background-repeat: no-repeat;
-webkit-text-fill-color: rgba(255, 255, 255, 0);
}
body {
background: black;
overflow: hidden;
}

While my p tag contains some text.

You can also use mix-blend-mode which determines how content should blend with the content of the element’s parent and the element’s background.

Source: MDN Web Docs

2. Linearly Scale Text In Accordance With Viewport

But it does not have to be so complicated and tiresome always.

Using just one line of CSS, you can scale text between a minimum and maximum sizes as the viewport increases or decreases.

Source: Author

This is done via the clamp property.

clamp(minimum, preferred, maximum);

The values are pretty self-explanatory. The clampproperty returns a value that is between the minimum and the maximum values. The middle argument, i.e. “preferred” is a percentage of the viewport.

Let’s see this in practice.

width: clamp(500px, 50%, 1500px);

When the viewport width is 1600px then the preferred value will be 50% of 1600px, that is, 800px. When the viewport is 700px, the preferred should be 50% of 700, that is, 350px.

But since the minimum is 500px, it will return 500px. The same logic applies to the maximum value of 1500px.

You can see from the media provided above as well. The minimum was 450px, hence you don’t see any change when the viewport becomes less than 900px.

3. Simple Photoshop

CSS offers various properties to manipulate images. Some of them are:

  1. Brightness: filter: brightness(90%)
  2. Blur: filter: blur(9px)
  3. Saturation: filter: saturate(4)
  4. Opacity: filter: oapcity(0.3)
  5. Hue: filter: hue-rotate(45deg)
  6. Drop Shadow: filter: drop-shadow(30px 10px 4px #4444dd)

The picture below has a blur filter applied to it.

img{
filter: blur(2px);
}
Source: plainenglish.io . Photo by Albert Dera on Unsplash

There are more filters and you can read about them here.

4. Fullscreen

Even Medium does it, when you click on an image it enlarges.

While you need JavaScript to make elements go full screen, by using the requestFullscreen() method, there is a CSS pseudo-class :fullscreen that allows you to style elements once they are in fullscreen mode.

:fullscreen {
background-color: yellow;
}

You can easily apply filters or change background(since elements that go full screen preserve their aspect ratio, leaving a white background behind).

5. Pie Charts

Using conic-gradient() CSS function, you can create images consisting of the gradient with color transitions rotated around a center point.

The most practical use case of this function, in my opinion, is creating pie charts.

background: conic-gradient(red 20%, purple 0 60%, yellow 0);
border-radius: 50%

The above code will render the following:

Source: Author

The result of the conic-gradient() function is an object of the <gradient> datatype.

You can find browser compatibility here.

6. Gradient Text

Chances are you already know how to work with gradients. If not, you can always use sites like Grabient which lets you customize the gradient and provide the CSS for it.

But do you know you can easily apply a gradient to text as well?

.text {
background: linear-gradient(to right, red 0%, purple 100%);
-webkit-background-clip: text;
-webkit-text-fill-color: transparent;
font: {
size: 10vw;
};
}

And you get awesome gradient text with just this.

Source: plainenglish.io

Conclusion

While you need JavaScript for functionality, HTML and CSS alone can help you build beautiful marketing and landing sites with bare minimum JavaScript(for converting leads).

I have seen many freelancers get away with just CSS and HTML skills.

If you are interested in HTML tricks, you can check my recent blog covering 5 HTML tips and tricks.

I hope you enjoyed this article!

More content at plainenglish.io

6 Fun Things You Can Do With Just CSS Tovább
A spreadsheet to compare job offers

A spreadsheet to compare job offers

spreadsheet-to-compare-job-offers-in-tech-458e97ff34.jpg

Introduction

A few times in my career, I've been fortunate enough to decide on which job I want most upon receiving multiple job offers.

I made a reusable spreadsheet which you can apply to your own prospective jobs, instructions at the bottom. Here are my personal observations on the pros and cons of two jobs I was evaluating.

They both made offers, so to decide between the two, I tallied them up against the following criteria:

The actual spreadsheet I used for two jobs in particular

Area of focus Place 1 Place 2 Notes
�️ Salary 1 More than xx% increase with Place 1
� Support for volunteering 1 Place 1: 3 days paid + XX days unpaid. Place 2 supports flexible hours, so would need to finish off my hours in the evening or weekend
� Culture 1 Place 2 is prestigious and has stimulating work
�️ Working from home 1 Place 2 said infrequently is ok. Place 1 could be multiple days a week
�️ Side projects 1 Place 2 support consulting + working with lots of interesting organisations. Place 1 offer hackdays
� Relaxed atmosphere 1 Place 1 is a large department with opportunity to do things in a relaxed manner. Place 2 is a smaller team, so the atmosphere may change during deadlines
�️ Maternity/paternity support 1 1 Both have good support in different ways
⚡️ Interesting projects 1 Lots of fascinating projects to work on at Place 2. Place 1 develops prison software + court software which is also interesting. Place 2 is more varied however
� Quality of code 1 Judging from respective GitHub projects, Place 1 has an extremely high level of code quality along with tests. Place 2 codebase has some room for improvement
� Peers 1 Place 2 team are a nice group of likeminded people. I don't know much about Place 1 folk
� Diversity 1 Place 2 team is all guys. Place 1 are much more diverse
� OSS + Evangelism 1 Place 1 do blogging + OSS by default. Lots of writing to read online, documentation for their projects, retrospectives, interactive demos. Place 2 have some open source code, couldn't find much blogging/written experiences. Both will support my conference speaking
� Career progression 1 More opportunity at Place 2. Place 1 seems to only lead onto managerial roles
� Technology architecture 1 Place 1 have established tools for CI/Testing/Deployments/Rollbacks/Code Review/Debugging/Development/Collaboration. Place 2 is smaller and appears to have less in place (based on GitHub)
� Lack of politics 1 Both have some, but Place 2 better protects you from it
� Technologies 1 Place 2 use very interesting + modern tech. Place 1 are starting to use modern tech, but also have some legacy code

Scores

  • Place 1: 9
  • Place 2: 8

To use this yourself, you can find the table on GitHub or use this Google Sheet

For more useful tips like this, follow me on twitter.

Update: Sonny raises an interesting point. They suggest adding two points:

  • Trust in what is promised
  • Possibility of adding the promises in the contract

Which I think are two very important points. Examples:

  • Trust in what is promised
    • It's entirely possible you're told "yes, we are flexible in allowing you to work from home", however it turns out that when you join, you're actually told "As long as your team says it's ok, it's fine" - but what happens when no one else on your specific team works from home?
    • I've also experienced hackdays being a big selling point, but in reality, you are peer pressured into using hackdays to fix bugs and do 'regular' tasks, like those related to technical debt

 

  • Adding the promises in the contract
    • Try not to be nervous about asking for them to add certain promises into the contract. In fact, for a previous government job I had (Place 1), I waited months before formally accepting the offer, all because I insisted they add a clause which guarantees me XX number of days of unpaid leave, so I could continue volunteering at a children's charity and a children's hospital. This meant as bosses and line managers come and go, and they start to question why I'm away so often, I can always refer them to the contract

Conclusion

Hopefully this spreadsheet, or maybe my thought process can give you some tips when deciding for yourself.

Also as a reminder: The actual pros/cons shown above are my personal opinion, and are not representative for the organisations as a whole in question, since I only interviewed with a single team in both cases.

 

Source: Umar Hansa - Webdeveloper

Let me know if you use any other criteria that could be helpful in the spreadsheet.

A spreadsheet to compare job offers Tovább
A UI design ereje

A UI design ereje

Olvasási idő: 3 perc

ui-blog.png

Szerepkörök, feladatok, és felhasználói igények

A UI mint „user interface”, a felhasználói felület tervezését jelenti. UI design esetében nem grafikusi munkáról van szó.

A cél túlmutat egy felhasználó-barát felület megtervezésén, a UI design veleje a megtervezett felület vonzó tálalásában rejlik.

 

Ki a UI designer és mi a szakterülete?

A UI szakember követi az aktuális design trendeket. Megtervezi a felhasználói felületeket, valamint animációkat és illusztrációkat hoz létre, amivel elősegíti az alkalmazás felhasználói élményben gazdag használatát.

A UI szakember

  • ismeri a felhasználói igényeket,
  • tervezés során felel az egységes megjelenés kialakításáért, mely érinti az animációkat, ikonokat, tipográfiát, illetve a fotókat is.
  • hatásköre továbbá a színvilág megtervezése az adott felületen,

legyen szó akár mobil app-ról, akár weboldalról.

Hogy szemléltessük a folyamatot, két igen különböző példát mutatunk be. Eltérő elvárások fogalmazódnak meg egy ipari környezetben használatos cél alkalmazás esetében, és más egy potenciális vásárlókat célzó fogyasztást ösztönző applikáció felületénél.

 

Törekedj az egyensúlyra

Egy gyári környezetben, egyszerűen a funkcionalitás és az iparági adottságok miatt elengedhetetlen a tervezett felület átlátható és egyszerű kezelése. Figyelembe kell vennünk olyan speciális munkakörülményeket, mint a

  • könnyű por képződés,
  • a kedvezőtlen fényviszonyok, vagy
  • a felhasználó védelmi öltözéke, például munkakesztyű használata.

 

Ellenben, a fogyasztói alkalmazások tervezésekor a megkapó vizuális élmény határozottan erőteljesebb hangsúlyt kap, így a UI designernek kiemelt figyelmet kell fordítania az aktuális trendek alkalmazására. A képi elemek tekintetében, - a célcsoport kiszolgálása érdekében -, nagyobb a tervező szabadsága, alkalmazhat:

  • animációt,
  • illusztrációs komponenseket,
  • sőt még humort is

a szegmens igényeinek megfelelően.

Fontos azonban a felhasználhatóság és a látvány közti egyensúly megteremtése, és annak fenntartása a teljes user journey (felhasználói útvonal) alatt.
A felsoroltak alapja azonban egy jól megtervezett UX design. A maradéktalan felhasználói élményhez kulcsfontosságú a két terület (UX & UI) összehangolt munkája.

Egy alkalmazás hibátlan megjelenése nem ellensúlyozza annak használatbéli hiányosságait. Ezen állítás fordítottja is igaz, egy jól átgondolt UX design, az alkalmazás könnyed használata nem váltja ki a felület megtervezéséhez szükséges UI kompetenciák alkalmazását. 

Természetesen a fejlesztők szerepe kihagyhatatlan egy, - a megrendelő számára -, jól működő alkalmazás, vagy szoftver készítésében. Termékünk azonban abban az esetben lesz valóban piacképes, ha azt felhasználói szinten öröm és élmény kezelni.

Ennélfogva minden projekt tervezésénél fordítsunk kiemelt figyelmet a UX-UI design folyamatok beépítésére, így igazi versenyelőnyre tehetünk szert.

 


 

A UX-UI design folyamat alkalmazása elemi üzleti érdek. A felgyorsult digitális transzformáció korában az lép előre, aki, - a user számára -, a leginkább felhasználóbarát, megnyerő és piacképes megoldást szállítja.

Forrás: Autsoft - Buday Mihály ( UI & UX designer )

A UI design ereje Tovább
Programozó lennék, de nem beszélek a nyelveden: Webdesigner & Sitebuilder & Frontend & Backend & Fullstack

Programozó lennék, de nem beszélek a nyelveden: Webdesigner & Sitebuilder & Frontend & Backend & Fullstack

Webfejlesztésnél, kliens és szerveroldalon mi történik?

full-stack-development-main.jpg

Elkezdett érdekelni a programozás világa, de még nem ismered ki magad a fogalmak között? Lehet hogy már tudatosult benned mivel akarsz foglalkozni, de még mai napig több forrásból hallasz kusza információkat egyes szakszavakkal kapcsolatban? Esetleg szimplán kiváncsi vagy, mert nem tudod merre az arra, és szeretnél letisztultabban látni a jövőddel kapcsolatban? Akkor jó helyen jársz, hiszen most egy tapasztalati és szorgalmas utánakeresős, érdeklődő cikket fogsz olvasni tőlem! 

Nagyon sokan dolgozunk azon, hogy amit a felhasználók látnak és tapasztalnak, megfelelően nézzen ki és működjön minden egyes alkalommal. 

Frontend fejlesztő v.1.: Sitebuilder 

A frontend szó jelentése elülső, szemből nézett elsőre nem sokat mondd a szakmáről, miért is van köze a fejlesztéshez, programozáshoz. De ha úgy mondom, hogy most is egy ilyen felületet nézel, akkor talán jobban megérted, mit is csinálhat egy ilyen szakember. Ez az a terület, mely a legközelebb áll a felhasználókhoz, a frontend az IT rendszerek legfelsőbb rétege. Ezt látod, ha felmész egy weboldalra, amikor ráviszed az egeret egy gombra és elváltozik a színe, ezzel is foglalkozik, de persze ez csak egy kis részterülete a szakmának, ezt nevezzük sitebuilder munkának. site = oldal builder = építő, amikor felépítjük a weboldal elemeit HTML vázzal és amikor stílust adunk az oldalunknak CSS-el, SCSS-el stb. ill. amikor az alap funkciókat JavaScript segítségével leprogramozzuk. 

Az igazi Frontend fejlesztő tehát nem csak programozási feladatokat képes ellátni, hanem annak a részegységeit is.

Frontend fejlesztő: 

A frontend fejlesztő az a személy, aki a sitebuilder képességeit profi szintre emeli, és ezt alkalmazza egy felhő alapú rendszer vagy magasabb komplexitású weboldal létrehozásához, kódolásához. A frontend fejlesztő, ahogy a sitebuilder is kap egy design tervet, az oldal vagy webes applikáció grafikai tervét, és ehhez megírja a kódot. Általában kkv szektorban a frontend fejlesztők sitebuilderek is egyben, mivel kis cégnél nem fognak megfizetni két embert ezeknek a feladatoknak az ellátására. Nagyobb cégeknél és multiknál már ezeket külön szedték, de léteznek olyan nagyobb cégek is, melyeknél valaki 8 órában csak Html-t és CSS-t ír, és valaki csak JavaScriptet, vagy csak valamilyen js keretrendszerben programozza a funkcionalitást, modulárisan létrehozva azokat az elemeket amik rá vannak bízva. 

Tehát a Frontend fejlesztés nem áll meg a HTML, CSS, és JavaScript együttesénél, és nem csak pixeltologatások vannak, meg gombok előreugrását kódolja le. Ezelőtt 6-7 évvel ha valaki ezeket tudta profi szinten elég volt az életben maradáshoz és a piacon való értéke sem volt kevés. Ma már ez nem igaz. Ha valaki igazi frontendes akar lenni, akkor nem elég csak ezekhez jól értenie. Ezeken kivűl használunk valamilyen JavaScript keretrendszert, a 3 legnépszerübb a React.js, Angular.js, Vue.js. Melyek már komolyabb applikációk, weboldalak, rendszerek programozásához szükséges skillek. Itt  már nem arról szól a történet, hogy HTML + CSS + JS-t ír a fejlesztő, itt már az adott termék funkcionalitását írja meg főként, és kevesebb HTML + CSS tudást igénylő a feladat. 

Dolgoztam olyan cégnél, ahol pár frontend fejlesztő alap html készségeit évekig nem használta, vagy csak alapból nem jól tanulta meg és (nem érdekelte hogy mélyebben utána nézzen, vagy csak hamar beszippantotta a munkaerőpiac) ezeknek a hatására én, mint junior amikor oda kerültem is tudtam új dolgokat mutatni nekik. Ebből a tanulság az, hogy egy igazi frontend fejlesztőnek a sitebuilder képességeinek ugyanannyira jónak kell lennie, mint annak, hogy jól programozzon le egy Üzenetek modult egy webes applikációban. 

Mik azok a JS keretrendszerek? Miért terjedtek el? Mire jók nekünk? React.js, Angular.js, Vue.js.

Itt most technikai eltérésekbe és VS játékokba nem mennék bele, ha valaki nem kezdő és érdekel a téma, vagy ha kezdő vagy és sztahanovista révén imádod terhelni az agyad itt egy jó kis cikk ezzel kapcsolatban angolul: Összehasonlítás más keretrendszerekkel.

vue.jpg

A JS keretrendszerek frontend technológiák, amik az alkalmazás fejlesztését szolgáló szabályok gyűjteménye. Ezen szabályok nagyon sokfélék lehetnek, vannak előre megírt keretrendszerek, amelyeket tipikusan egy fejlesztői közösség dolgozott ki pl a Google, és talált megfelelőnek, de keretrendszert egy fejlesztő maga is kidolgozhat, ezek a saját keretrendszerek (framework-ök). Csak itt, ha a fejlesztő nem követ bizonyos modelleket, akkor a végén nem tudhatjuk mire is gondolt a költő.

Ezekről a tervezési mintákról és modellekről majd egy másik cikkben teszek említést. Kicsit leegyszerűsitve a dolgot, a JS keretrendszerek által kevesebb a spagetti kód és mert mindennek megvan a helye, komponensekben gondolkozunk és a szabályaik, elveik szerint kódolunk.

Ezeket a kódolási standardokat minden fejlesztő ismerni fogja, és ha véletlenül Gipsz Jakab lelép a cégtől, akkor könnyedén találunk a helyére embert, mert nem a nativ JS-es kódját, vagy a Jquery-s (JavaScript könyvtár) x-soros kódját kell kihámoznia. Ez által az egységesség által pedig a kód is ujrafelhasználhatóvá válik más projektekben is, és átlathatóbb is lesz. Nyilván nem minden projekt esetében használjuk ezeket, hiszen ágyuval verébre nem igazán jó lőni.  Mindegyik technológiának vannak előnyös és kevésbé kedvelt tulajdonságai. Amit minden esetben szem előtt kell tartani, mikor letesszük a voksunkat egyik vagy másik mellett. Mindig az adott feladathoz, projekthez, problémamegoldásához választunk nyelvet és technológiát, és nem forditva. :)

React, Angular vagy Vue.js – frontend framework esetén ők a „piacvezetők”, és a „legjobbak”. 
Pár szóban róluk:

Ha sorrendbe kellene tennem őket véleményem szerint ma ami legkeresettebb a React, utána tenném az Angulart, és a végére a Vue.js-t. Én se értek mind a 3-hoz hozzáteszem, én a Vue-vel kezdtem el, nekem az könnyebb volt kisebb feladatokra bizonyos webes alkalmazásoknál. De én is szeretnék pl. Reactot tanulni, már jelentkeztem is egy céghez projektmunkára, ahol tanulni is tudnék React-ot és Vue-t együtt. A Reactról mindenki tudja, hogy a Facebook nyelve, az Angular a Google gyermeke, a Vue-t Evan You hozta létre, miután számos projektben a Google-nél dolgozott az AngularJS használatával. 

React kiemelve pár szóban


Azért emelném ezt ki jobban, mert mostanában kb. a csapból is ez folyik ha Frontendes állást látok, ill. a barátaim és a Mentorom és jobarátom Milán is ezt emelte ki nekem. A Reactot a Facebook fejlesztette ki 7 évvel ezelőtt, pontosabban Jordan Walke, a Facebook szoftvermérnöke készítette. A react egyik cikkjében, melyet 2013-ban publikáltak egy kérdéssel indul el a cikk, amely magyarul igy hangzik: 

Nagyon sok JavaScript MVC keretrendszer létezik. Miért építettük a React-et, és miért akarod használni?

Nos a cikkben ami nekem  személy szerint a legfontosabb szempont és ami a legjobban is tetszik: 

Reactive updates are dead simple. React really shines when your data changes over time.
(A reaktív frissítések rendkívül egyszerűek. A React igazán ragyogó, amikor adatok idővel változnak.)

Ha érdekel a cikk, angolul eléred az oldalukon: Why did we build React?

Most itt a kezdőknek szóló cikkemben nem szeretnék mélyebben a témába menni, inkább számomra érdekes témákat boncolgatnék. Ha szeretnél olvasni erről mélyebben itt megteheted. Úgy érzem a fentiek elolvasásával kaptunk egy kisebb betekintést abba, mit is csinál egy sitebuilder és egy frontend fejlesztő. Ezt nevezzük kliens oldali programozásnak, fejlesztésnek.

Ehhez a szakmához szükséges van HTML5, CSS3, Native JS, valamilyen JS framework ismeretre, CSS preprocessorokkal képbe vagyunk (SASS, Less), van nemi design érzékünk, egy alap Photoshop vagy egy Figma használat sem okoz gondot, a jQuery kis projekteknél sem ellenségünk, az npm, yarn, webpack és a GIT a legjobb barátunk, egy SQL lekérdezéstől nem halunk meg, ha magunknak kell megírni, láttunk már MVC keretrendszereket, kb. ismerjük azokat, PHP nyelvet sokat láttunk, másolgattunk esetleg problémákat oldottunk meg bennük, a Flexbox-ról tudjuk hogy nem flexelésre használjuk a garázsban, a CSS grid és a Bootstrap grid-ről nem az börtönrács jut az eszünkbe, az hogy ebből 12-őt használnak általában, nem lepődünk meg.

És akkor meg a negyedét se emeltem ki azoknak az eszközöknek, sablon motoroknak (template engine), SEO követelményeknek amivel képben kell lennünk. Szóval amikor valaki azt mondja, hogy a frontend könnyű, az nem igazán tudja hogy miről beszél. Mindegyik ágazatnak megvan a nehézsége és a könnyedsége.

De ha már más ágazatok és fogalmak. Mi is az a backend? Mi is az a Fullstack?

inner-03.png


A backend a frontend ellentéte, de mégis szorosan összekapcsolódik a kettő, mondhatni, hogy legjobb barátoknak kellene lenniük a frontendeseknek és a backendeseknek, de a valóságban mégis sok ellentét van a két szakma között, sokszor hallani nárcisztikus elejtéseket azzal kapcsolatban, hogy a frontend az nem programozás, mert hát az nem egy C, vagy C++, vagy egy Java, de hát felesleges is összehasonlitani ezeket, mert más területek. És aki ezt mondja, az előbb tanulja meg a fentiek használatát precízen, húzzon fel egy maga egy weboldalt mondjuk PSD alapján pixelpontosan, és ha eljutott oda, hogy nem csak HTML, CSS-el megy ez, hanem mondjuk egy SASS-al, egy Flexboxxal, egy Handlebar.js, vagy Mustache template engine-nel, mellette valamilyen JS frameworkben programoz le bizonyos funkciókat, akkor majd beszélhetünk arról, mi miért is nehéz. :D

Na de, mi van akkor ha tényleg imádja egymást a két terület? Hát akkor születnek a csodák, melyek egyik terület nélkül sem létezhetnének. A backend fejlesztő a szerver oldalért felelős, a weboldalak többsége 80%-a még mindig PHP nyelven íródik, obejktum orientált szemleletmód mentén, a maradék 20%-a pedig egyéb mint pl a Java  melynek segítségével gyors, reszponzív, skálázható web alkalmazások készíthetők nagy terheltségű, összetett webes feladatok kiszolgálására. Ami mostanában felkapott lett pedig a Go nyelv, könnyen tanulható, gyors, jól skálázható, megbízható és nagy teljesítményű, biztonságos programnyelv. Na de, mit csinál mégis a backendes?

A feladatuk szintén összetett. Fogja azokat az általam írt kódokat és dinamizálja. Az adatbázisban létrehozott táblákban az adatokat összekapcsolja az általam megírt kódokkal és lehetővé teszi az adatbázissal támogatott dinamikus weboldalak futtatását a webszerveren.

Ilyenkor az adatok nem beleégnek a weboldal HTML vázába, hanem dinamikusan cserélhetőek, az ügyfelek admin felületen könnyedén tudják cserélni a weboldal tartalmát. Írnak olyan funkciókat, hogy a híreket listázza az oldal, a regisztrációt, belépést megvalósitják, az adatok tárolását biztonságossá teszik, és még megannyi feladat. Ők is értenek kicsit a HTML, CSS, JS-hez, elkerülhetetlen ez a készség, hiszen vannak olyan feladatok, ahol találkoznak eféle kódokkal is.

De mi van akkor ha valaki Frontendben és Backendben is profi? Na olyan nincs! Ez persze az én véleményem, de azt tapasztaltam, hogy valamelyik terület mindig erősebb lesz, valamelyik mindig jobban érdekelni fogja az szafiofil embereket. Szokták mondani, hogy aki mind a kettőhöz ért az a fullstack fejlesztő. Ez nem teljesen igaz így, ha valaki frontendben erősebb akkor ő Fullstack Frontend Fejlesztő lesz, ha backend a jobb, akkor pedig Fullstack Backend Fejlesztő, de az igazi Fullstack fejlesztő nem csak ennek a kettőnek az együtteséhez ért, hanem a DevOps-hoz. (a fejlesztés (Development) és az üzemeltetés (Operations) viszonyának javítását takarja.) és Rendszergazda ismeretei is vannak. A DevOps fejlesztő az, aki figyeli és működteti a termékmenedzsment, a szoftverfejlesztés és a műveleti szakemberek közötti kommunikációt és együttműködést. Olyan vállalati kultúra és környezet létrehozásával próbálja automatizálni a szoftverintegráció, a tesztelés, a telepítés és az egyéb változások folyamatát, ahol a szoftverek építése, tesztelése és kiadása gyorsan, gyakran és többször is megtörténhet. A rendszergazda vagy másnéven a sysadmin egy olyan fogaskerék a gépezetben, aki felelős a számítógépes rendszerek karbantartásáért, konfigurálásáért és megbízható működéséért; szerverekért.

Olyan emberrel még nem találkoztam, aki mindezekben kiváló, viszont attól még létezhet, meg létező állás is a Fullstack-es. Ez kb olyan, hogy én most Frontendes poziban dolgozok, de lehet jövőhéten egy másik cégnél már Fullstack-nek számítanék. Értitek, valós a dolog, de azért szerintem, ha valaki ezt így magára aggatja 10-20 éve fejlesztő emberek joggal nevetik ki emiatt. Mindeki döntse el maga, milyen skatulyába szeretne tartozni, és mi az ami jobban érdekli.

Webfejlesztő vs minden egyéb

A fentebbi dolgok hozzátartoznak a webfejlesztéshez is. Sokszor olvasok olyan álláshirdetéseket, hogy már kb. azt nem várják el egy webfejlesztőtől, hogy a portás is ő legyen, ezek vagy kókler cégek, ahova nem szabad menni dolgozni, vagy csak nem hozzáértő írta az álláshírdetést. Általában az olyan posztok, ahol szeretnék ha a webfejlesztő értene a PHP-hoz és a JS-hez is valójában Fullstackes fejlesztőt keresnek valamelyik területben erősebbet.

Ugyanis régebben nem különültek el ezek egymástól ezelőtt 10 évvel, emiatt is van az, hogy mocskosul lassú és undorító design-nal, frontend-el megáldott oldalak születtek. Ma már nem lehet elvárni hogy egy ember végezzen ilyen magas komplexitású nyelvek és eszközök mellett minden munkát. Az átlag programozó se zseni, csak emberek, akik képesek voltak seggelni éveken át a tudást, és volt elég szorgalmuk, kiitartásuk és motivációjuk, hogy ebbe a szakmában maradjanak. Ma már ha nagyobb weboldal kell, ahol kell admin, belépés, regisztráció, akkor elengedhetetlen az elkülönítés akkor ha a webdesign nem egyszerű, hanem asszimetrikus, absztrakt, nagyon trendi. Ezekhez már design érzékek kellenek, amit egy backendes nem minden esetben tud megvalósitani egymaga.


De mi is az a webdesign? Webdesigner? Ux designer? UI designer? Grafikus? 


A webdesign az, amibe mi Frontend fejlesztők lehelünk életet, melyet a webdesigner tervez meg különböző eszközök segítségével. Amiket általában használnak: Adobe Illustrator, Photoshop, InDesign, After Effects, Adobe XD és Premier Pro, Blender. Mindegyik más más eszköz, melyek némileg kapcsolódnak egymáshoz. Itt is a webdesigner dönti el, hogy adott tervezéshez mit használ. Ide tartoznak még a prototípuskezelők is, mint a Figma, InVision etc.

De mitől lesz a webdesigner UX designer? A UX szó, USER EXPERIENCE, azaz felhasználói élmény, felhasználói tapasztalat. Az a webdesigner, aki ilyen képességekkel is rendelkezik, válik UX designerré. A UI pedig a USER INTERFACE design-nal foglalkozik. A UX-es adatokkal foglalkozik, tervet készit, versenytársakat elemez,  minden interakciót megtervez, amikor a felhasználó kapcsolatba lép az oldallal és a termékkel, ezekhez drótvázakat készit, működő prototípusokat hoz létre. A megértését alapvetően az is bonyolitja hogy egy élményt nem lehet megtervezni szó szerint. Maga az élmény a felhasználóban keletkezik amikor interakcióba lép az általunk tervezett szolgáltatással. Ehhez pedig tisztában kell lennünk az ügyféligényekkel, hogy kik a célcsoport és mit akarunk a végfelhasználóktól, milyen érzéssel távozzanak. A UX és a usability (használható) erősen kapcsolódik egymáshoz, hiszen a UX-es könnyen használható felületeket tervez, melyek nem rontják a felhasználói élményt sem. Pl. minél kevesebb kattintással jusson el a cáljához, amiért az oldalunkat valószinűleg használni fogja. Ha érdekel a téma ezen az oldalon részletesen tudsz olvasni róla. Itt pedig lentebb görgetve találsz tematikát a témával kapcsolatban.

Ma már szinte mindenki UX designer meg UI designer, meg Webdesigner, aztán azt se tudják mi a micsoda. Lényegi különbség azon is van, hogy egy webdesigner-nek illik ismerni a HTML+ CSS viszonyát, ill. ezeknek a megjelenési formáit, grid rendszereket. Az éppen aktuális CSS keretrendszert pl. Bootstrap 4-re milyen designt jó tervezni, etc. azt csak úgy tudja, ha ismeri. 

A grafikusok olyan szakemberek akik képesek nyomdailag megfelelő logókat és grafikai objektumokat készíteni, képeket előkészíteni és szerkeszteni nyomdai felhasználásra, valamint a grafikus részeket egy komplett kiadványban egyesíteni és nyomdakészen publikálni, a grafikai ismereteiket webes animáció készítésben is tudják kamatoztatni. A grafikus, mint szakma szinte szégyenfolt lett, nem írják ki, mert hát ma már nem ez a trendi, viszont nem is képzik magukat eléggé ahhoz, hogy webdesignerek legyenek. Persze akinek nem inge, az nem öltözködik, de ugyanez vonatkozik a programozói világra is, ha nem képzed magad állandóan, aggathatsz magadra bármilyen titulust, és előadhatod zseniséged mivoltát olyannak, aki nem jártas a témában, de amikor egyedül vagy egy projektben és bizonyítani kell, magadban mélyen, úgyis tudod miben kell még fejlődni, és valójában hova tartozol most a jelenben, és azt is hol akarsz lenni x év múlva.

Amit én minden embernek tanácsolnék, az-az, hogy járjon utána először annak, tényleg érdekli-e az adott szakterület, mert a motiváció hiánya a legnagyobb zseniket is összeroppantja a munkaerő piacon. Kitartás kelleni fog, és egy jó szék a derekadnak. :) De valamit valamiért nem? :) 

Ha eddig eljutottál olvasásban, akkor köszönöm. Ha tetszett a cikk hagyj egy kommentet, vagy oszd meg olyan emberekkel, akiket szintén érdekelhet a téma. Üdv. egy Frontend lány. 

Programozó lennék, de nem beszélek a nyelveden: Webdesigner & Sitebuilder & Frontend & Backend & Fullstack Tovább
süti beállítások módosítása