LF(?)M NodeJS/Python part-time/freelancer coder

Olyan jól sikerült az előző körös analyst recruit felhívás, hogy annak sikerét kihasználva szeretnék egy újabb felhívást tenni. Nem tudom megállni, hogy ne tegyek a téma kapcsán azonban egy fricskát: multis/nagybankos vezetőként közel 10 évig szenvedtem a(z) <insert random jobportal>-(va-)/(ve-)l, ahol kulcsfontosságú pozíciókra tudtak hozni negyedév alatt  3-4 egyébként teljesen alkalmatlan jelentkezőt. Ehhez képest a saját tematikus blogomra feldobok a saját stílusomban egy recuritot, amire egyből beesik több mint egy tucat jelentkező, akik nagy része egyébként már túl van a második körön és éppen a shortlist összeállításán ügyködünk. Emlékszem a 2000-es évek első felében volt ilyen a piac, amikor egy IT biztonsági szakértő vagy php fejlesztő pozícióra akár 40-60 ajánlat is érkezett, melyek igen nagy része egyébként teljesen passzolt is az avatarba.

Szóval ezen fellelkesülve futnék még egy kört: Jelenleg bejáratott frontend programozó csapattagunk üveghangon dolgozik most kb 3-4 projekten, viszont az élet nem áll meg, ezért szeretnénk bővíteni a csapatot. Jelenleg ebben a témában biztosan nem tudunk/akarunk fulltime foglalkoztatni valakit, ezért mindenképp freelancer vagy parttime munkaerőt keresnénk.

Elvárások: NodeJS/Javascript készségszintű tudás, ajax/async alapú dinamikus tartalom management. Nem kell felületeket és folyamatokat tervezni, ezeket készen kapod, viszont ne okozzon kihívást, ha egy vektorosan lerenderelt felülettervet pixel pontosan kell implementálnod a runtime kódban. RestAPI/WSGI és JSON leíró formátum készség szintű ismerete szintén elvárás.

Mivel kell foglalkozni: Az Inlock meglévő fejlesztései mellett számos egyéb kisebb/nagyobb jellemzően crypto és blockchain orientált projektek fejlesztése.

Ami előnyt jelent: komoly előny, ha pythonban foglalkoztál már WSGI-vel (pl Flask) vagy bármilyen más python alapú API frameworkkel. Az is jó persze, ha bármilyen más környezetben foglalkozál API fejlesztéssel… már persze, ha nem gond, hogy megtanuld ugyanezt python/flask-en is. Szintén nagyon komoly előnyt jelent, ha nem most ezt olvasva hallasz először az ElasticSearchről.  Ha mégis így lenne és szeretnél legalább képbe kerülni, akkor: https://variance.hu/?s=ElasticSearch

A projektek, fejlesztések és issuek trackelésére asanát használunk, így könnyedén tudsz akár a világ másik végérők is dolgozni, de persze komoly előnyt jelent, ha heti/két heti rendszerességgel azért el tudsz jönni egy followup meetingre, hogy személyesen is át tudjuk beszélni az progresst.

Szintén előnyt jelent, ha fejből vágod az összes WoW kieg 10+ raid instance főbossának nevét és halványan emlékszel is még esetleg a taktika főbb lépéseire, különösen ugye illidanra és c’thunra. Bár ezen előnynek úgy egyébként nincs semmi köze a konkrét munkához…

Mit kínálunk: blockchain, tokenizáció és kriptopénz alapú projekteken tudsz úgy tanulni, hogy közben a meglévő tudásodat és képességeidet is tudod hasznosítani. A jelenlegi informatika és pénzügyi szakma kreatív egyvelegét, ami a nálunk okosabbak szerint is meg fogja változtatni a világot, ha szerinted ott a helyed a jégtörők között, akkor keresve sem tudnál ennél jobb helyet találni magadnak. Mivel jelenleg freelancer pozícióba keresünk kódert, ezért minden projektnél magad fogod tudni eldönteni, hogy érdekel avagy sem az adott téma annyira, hogy csatlakozz. Persze ettől függetlenül nem zárjuk ki a lehetőséget, hogy záros határidőn belül internalizálnánk ezt a feladatot is.

Ha úgy gondolod, hogy szeretnél velünk dolgozni, akkor mindenek előtt NE küldj CV-t nekünk! Helyette végezd el a tovább után található feladatot, ennek eredményét küld el a blog kapcsolat email címére. Ha tetszik a gondolkodásmódod, akkor felvesszük veled a kapcsolatot… Már persze, ha kapunk az emailben elérhetőséget is.

Folytatás…

Timeseries vizualizáció: Kibana Timelion

Jelenlegi post még a timelion funkcionalitására épül, azonban itt jegyezném meg, hogy az 5.4-es főverzió kapcsán kiadott közlemény alapján ezek a funkciók (vagy legalábbis nagy részük) már elérhető lesz közvetlenül a beépített Kibana vizualizációs eszközökkel is. Addig is amíg nem kerül kiadásra az 5.4, viszont marad a timelion. A timelion eredetileg egy függetlenül fejlesztett Kibana plugin volt, ami az 5.0-ás főverziótól kezdődően beépült az alap Kibana funkciók közül (a Sense pluginnal együtt).

A timelion talán legfontosabb funkciója az összehasonlítható és vizuálisan részletgazdagabb chartok képessége. Mindemellett a timelionban készített vizualizációk minden gond nélkül rárakhatók tetszőleges dashboardra vegyesen akármilyen más Kibanás vizualizációval együtt.

Folytatás…

Big Data: Hadoop vs Elasticsearch, mond Te mit választanál?

Amikor napjainkban előkerül az a kifejezés, hogy Big Data, akkor ennek a hátterében (technológiai értelemben) vagy egy Hadoop alapú környezet, vagy egy Elasticsearch áll. Vagy persze ennek valamilyen jellegű kombinációja. (pl hdfs alapú adattárolás mellett nosource indexed elasticsearch kereséshez).

Ez a két technológia lényegében uralja a piacot. Előbbi ugye egy robosztus rendszer, ami modulok és célalkalmazások százait vonultatja fel, az utóbbi pedig leginkább keresésre való, de arra viszont nagyon. A megközelítéssel ugye az a baj, hogy a Big Data mint kifejezés pont annyira egzakt mint mondjuk a “cloud”. Tehát önmagában semmit sem jelent és lényegében bármire lehet használni.  A megvalószítás technológiai eszközének kiválasztásához nem árt végig gondolni, hogy mit is akarunk tárolni a big data-ban és mit is akarunk azzal csinálni.

Folytatás…

Zero downtime in ELK (Elasticsearch) environment

Nem visz rá a lélek, hogy ez a címet magyarul akarjam leírni… De miért is érdekes a zero downtime egy NoSQL megoldás kapcsán. A héten került megrendezésre a HOUG nevű szakmai konferencia Siófokon, ami a hazai Oracle felhasználók éves nagy konferenciája, ahol megannyi sales fókuszú előadás mellett bőven akadt szakmai előadás is, melyek egy része bőségesen adott gondolkodnivalót nekem is. Az egyik előadáson lőttem az alábbi ábrát (remélem nem kövez meg senki amiért nyúlom…):

Folytatás…

Hogyan joinoljunk Elasticsearchben?

Oké, ennyire hülye címet is már régen adtam bármilyen postnak. De lássuk csak, hogy miről is akar ez szólni. Ugye a JOIN egy közkedvelt eszköze a relációs (RDBMS) adatbáziskezelőknek, ami pont az a tulajdonságot használja ki, hogy az adatbázis relációs és annak tartalma normalizált ÉS feltételezhetően vannak benne relációk. Ezen relációk adják az RDBMS rendszerek valódi lépéselőnyét a saját pályájukon. A JOIN lényege az, hogy egy vagy több tábla között létrehozunk logikai kapcsolatot és ezen kapcsolatokon keresztül bonyolult lekéréseket tudunk létrehozni. (vagy éppen ki tudjuk nyírni az egész RDBMS-t egy gyönyörű kaszkád szorzással…)
Namost az Elasticsearch az sem nem RDBMS, sem nincsennek benne reálciók (óóó, dehogy nincs… lásd a cikk végén a parent/child relációt…) és úgy egyébként a JOIN-nak sincs semmi értelme benne. Miért is nincs értelme a JOIN-nak? Az Elasticsearch (és igaz ez a legtöbb key=value alapú NoSQL motorra) pont arra az elvre épül fel, hogy minden egyes dokumentum önálló elem melyek önmagukban értemezhetők és esetleg valamilyen statisztikai elemzést vagy aggregációt akarhatunk rajta végrehajta. Mivel erre van optimalizálva az egész motor, ezért semmi értelme az olyan relációs adatmodellnek, ahol egy indexben tárolunk mondjuk dokumentumokat és felhasználói ID-kat, egy másik indexben pedig tárolunk a felhasználói ID-khoz tartozó neveket és egyéb adatokat. Sokkal egyszerűbb minden releváns adatot minden dokumentum esetén tárolni, hiszen a háttérben a NoSQL motor gondoskodik arról, hogy ezek az adatok ne redundánsan tárolódjanak. Ráadásul az ilyen erőltetett kereszthivatkozások csak lassítják is a keresési performanciát.
Folytatás…

Tisztázzuk az alapokat: big data, nosql, ES, APM

Mielőtt nagyon belemélyednél a konkrét témákba (lásd címben), talán érdemes tisztázni, hogy mit is jelentenek ezek a fogalmak, mi közük van egymáshoz és konkrétan én mit értek ezeken. Ebben a postban véletlenül sem szeretném tudományos alapokig részletezni és szakmailag sem mennék bele. Célom csak egy általános kép kifejtése azoknak, akik csak most ismerkednek ezekkel a fogalmakkal.
Big data: kezdeném is mindjárt a legnagyobb lufival. Kezdetben vala a strukturált adattárolás, amikor (az ősidőkben) még luxus volt az adattár, jól végig gondoltuk, hogy mit is akarunk tárolni és törekedtünk arra, hogy ezt a leginkább optimális módon tegyük. Ezzel együtt eljött az internet, eljöttek a felhők (nem… nem a skynet) és eljött mindaz, ami ma jellemzi az adattárolást. Az olcsó adattárolás, a mesterséges(-nek tűnő) intelligencia (gépi tanulás) és strukturálhatatlan adatkörök miatt jöt létre az a valami, amit big datanak nevezünk. Mi jellemzi ezt: gyakorlatilag mindent tárolunk amilyen adatot csak elő tudunk állítani, annak minősége, jellege és értelme nélkül, mindezt tesszük azzal a szándékkal, hogy később feltételezhetően fel fogunk fedezni olyan összefüggéseket, amik értelmet adnak a strukturálatlan adatnak. A régi mondás, mely szerint “a kevesebb több”, mára átalakult a “több az több lehet” mondássá.
Folytatás…

ELK: Több Elasticsearch [ES] node futtatása egy hoston

Aki ismeri az Elasticsearch [ES] filozófiáját, az pontosan tudja, hogy alap esetben semmi érteme nincs annak, hogy egy hoston több nodeot futtassunk, hiszen mi is az ES esszenciája: Végy egy halom középkategóriás, olcsón fenntartható gépet, majd minden különösebb technológiai tudás nélkül rakd fel rájuk az ES-t, kapcsold öket egy clusterbe és jöhet a fun. Ha pedig mégsem jön, mert ez így nem elég hatékony, akkor optimalizáld a shardok eloszlását, rakj hozzá a clusterhez még néhány gépet és ezen egyszerű eszközökkel lényegében bármikor tudod skálázni a clustert.

Azonban nagyvállalati környezetben előfordul, hogy középkategóriás olcsó gépek helyett komolyabb vasak kerülnek a kijelölésre. Ilyenkor meg kell tudni találni az ésszerű középutat. Egy önálló ES node kapcsán van néhány olyan technikai függőség, ami meghatározza, hogy maximum mennyi erőforrást tud optimálisan használni. Ezen függőségek közül a leginkább fontos talán a heap size:

  • Az elasticsearch technológiailag java virtuális gépben fut, aminek a heap kezelése erősen kihathat az ES működésére. Technológiai adottság, hogy 32Gb heap size alatt a JVM compressed object pointer (compressed oops) technológiát használ a heap kezelésére, ez felett már nem lehet használni ezt az opciót, ami jelentősen rontja a JVM hatékonyságát.

Folytatás…