Reguláris kifejezés: Gyorstalpaló

A reguláris kifejezés nem mondanám, hogy fiatal. Nagyon kevés ember ismeri őket és még kevesebb úgy igazán. Gyakran előfordul, hogy megkeresnek ennek kapcsán emberek. Itt most nem 1-2 emberről van szó. A postafiókomban rákerstem a reguláris kifejezésre, ahol nem én vagyok a küldő és az elmúlt 6 hónapban 84 levelem van. Ez mind magyar levél és igen nagy százalékban kérdés.

(tovább…)

Kapcsolódó cikkek:

Ingyen Pro-val ünnepel a JuiceSSH

Androidra régóta vár már mindenki a szakmában értelmes SSH kliensre. Mindig voltak próbálkozások, de valami sose volt az igazi. Valahol beépített billentyűzettel próbálták javítani a használatot, de az elég lassú volt. Volt a hol minden jó volt, de például RSA és DSA kulcsokat nem lehetett hozzárendelni. Lényegében használhatatlan volt mind, legalábbis számomra.

Az első értelmes kliens a JuiceSSH volt, ami már Pro felhasználó nélkül is remekül használható. Nagyjából csak a snippetekhez nem fér hozzá az ember, ha nem fizet, de mint SSH kliens, teljes mértékben használható.

(tovább…)

Kapcsolódó cikkek:

mloc.js 2014 – JS ninjas about upcoming JavaScript & Browser features?

A mloc.js második előadását Daniel Steigerwald tartotta. Elsősorban az ES6 volt a téma, de sok más érdekes dolog is előkerült. Így elsőre nekem az ES6 (ECMAScript 6) kevésbé tetszik. Nagyjából a CoffeScript pár finomságát vette át, viszont — ahogyan Daniel is említette — sokkal nagyobb teret ad nekünk, hogy csúnya kódot tudjuk írni. Amitől beszélt az tulajdonképpen a JavaScript idénre várható dolgai. Számomta ez volt az egyik legfurább eddig az egész mloc.js konferencián.

(tovább…)

Kapcsolódó cikkek:

mloc.js 2014 – Release the Kraken

(A képet köszönjük Gábor Török)

Elérkezett idén is a mloc.js konferencia is, amiről korábban már írtam. Szép számmal vagyunk jelen, nagyon sok országból. Van itt amerikai, iráni, osztrák, norvég és már nagyon sok más országból tudásra vágyó ember. Az összes jegy elkelt, amiből volt aki nem jött el, de nem sok biléta maradt az asztalon. Csak a fele magyar a többi valahonnan máshonnan jött, ez is mutatva, hogy nem kis eseményről van szó.

(tovább…)

Kapcsolódó cikkek:

mloc.js 2014

Idén is előkerült a mloc.js és már nagyon közel van. Tavaly sajnos nem tudtam ott lenni, de idén már biztosan sikerül február 13-án és 14-én ott lennem.

Van még pár óra, amíg elővételben olcsóbban meg lehet venni. Egészen pontosan $222 (~49ezer magyar forint) ma este 6-ig, míg utána $260 (~57ezer magyar forint) lesz az ára.

Közben kaptam egy kis igazítást András Bártházitól:

Tavaly a Design Terminalban volt, idén a Prezi új “House of Ideas” előadótermében lesz (az iroda épületében, de nem az
irodában)

@ba78

Tömören, röviden

It’s happening, JavaScript is one of the most popular languages and it’s conquering the server side and the internet of things as well. JavaScript is just eighteen years old, and the future is bright. But how this future looks like? How can we improve JavaScript to make it better, focusing on large scale projects with millions lines of code?

Forrás: mloc-js.com — About

Miért éri meg?

  • Nagyon hangzatos a az előadók listája:
    • Eddy Bruel — Mozilla (How JavaScript Objects are Implemented)
    • Maxime Chevalier-Boisvert — Université de Montréal (JIT compilation techniques)
    • Domenic Denicola — Lab49 (Streams for the Web)
    • Anton Ekblad — Chalmers University of Technology (Hastily Paving the Way for Diversity)
    • Alexander Fritze — OniLabs (Building real-time web applications with Stratified JavaScript)
    • David Galeano — Turbulenz (JavaScript and the browser as a platform for game development)
    • Jeff Harrell — Paypal (Release the Kraken)
    • Shriram Krishnamurthi — Brown University (JavaScript as an Intermediate Language)
    • Guillaume Lathoud (JS optimization techniques)
    • Miguel Ángel Pastor — Halfbrick Studios
    • Alessandro Pignotti — Leaning Technologies Ltd. (Duetto: C++ as the platform language for the Web)
    • Jaswanth Sreeram — Intel Corporation (Parallel Javascript)
    • Stoyan Stefanov — Facebook
    • Daniel Steigerwald (What should the average JS ninja know about upcoming JavaScript and Browser features?)
    • Ben L. Titzer — Google (New optimizations of Google Chrome’s V8)
  • A fenti felsorolásban a címek még izgalmasabbak
  • Találkozhatsz sok emberrel
  • Nagyon sokat tanulhatsz

Ízelítőnek

Hogy nagyobb rálátást kapjon mindenki mi is ez, itt egy videós összefoglaló a tavalyi évről.

Az én jegyem már megvan. Te jössz?

Kapcsolódó cikkek:

Array metódusok, amiket jó tudni

Ha valaki foglalkozott már egy kicsit is JavaScript-el, az legalább egy ciklust írt. A tömbök (array) nagyon fontos elemei szinte minden nyelvnek (már amennyiben létezik).

De vajon kihasználjuk a tudását és nem írunk feleslegesen ciklustokba ágyazott cilusokat, amik csak azért vannak, hogy egy másik tömböt felépítsünk vagy egy változó értékét true/false értékkel töltsünk meg? Először nézzünk olyanokat, amiket talán sokan ismernek. Később majd előveszünk ritkábban tudottakat is.

Array.forEach

Gyakran látható az alábbi kódrész:

var myArray = ["Ez", "egy", "tömb."];

for (var i = 0, _l = myArray.length; i < _l; i++) {
  if (myArray[i].length > 2) {
    // A console.log a paramétereit szóközzel összefűzve írja ki.
    console.log("Itt egy hosszú szó:", myArray[i]);
  }
}

Erre bizony van a tömböknek saját függvényük, amiket nyugodtan lehet használni. A forEach pont arra való, amit a neve is mutat. Végighalad az összes elemen. Egy hátránya van: Nem lehet belőle kilépni, tehát itt nincs break. Továbbmenni egyszerűen egy return-el lehet 🙂 De mint később látni fogjuk a break is megoldható. A forEach három paramétert kap, amit vagy felhasználunk vagy nem. Első az adott elem (igen nem az index-et adja először, mert a legtöbb esetben az elemre van szükség). Második az index és harmadik értéknek kompletten a tömböt kapjuk meg. Lássuk a fenti példát már az újonan megismert függvényünkkel:

var myArray = ["Ez", "egy", "tömb."];

myArray.forEach(function(item) {
  if (item.length > 2) {
    // A console.log a paramétereit szóközzel összefűzve írja ki.
    console.log("Itt egy hosszú szó:", item);
  }
});

De akár kitehetjük külön függvénybe is, ha a műveletet többször szeretnénk futtatnk:

var logIfLongWord = function(word) {
  if (word.length > 2) {
    // A console.log a paramétereit szóközzel összefűzve írja ki.
    console.log("Itt egy hosszú szó:", word);
  }
};

myArray.forEach(logIfLongWord);

Array.join

Kicsit kevesebbszer találkozunk az alábbi kódszerkezettel, de ez sem ritka:

var myArray = ["Ez", "egy", "tömb."],
    sentence = "";

for (var i = 0, _l = myArray.length; i < _l; i++) {
  if (sentence.length > 0) {
    sentence += " ";
  }
  sentence += myArray[i];
}

Egy nagyon jó megoldás van erre, amit úgy hívnak, hogy join. Megadhatjuk, hogy mivel fűzze össze a tömbünk elemeit.

var myArray = ["Ez", "egy", "tömb."],
    sentence = myArray.join(" ");

Mennyivel egyszerűbb nem? 🙂

Array.map

Ez talán az általam legtöbbet használt metódus. Szerintem többet használom, mint a console.log, console.error-on kívül minden mást. Egy egyszerű callback függvényt vár paraméterben és a forEach-hez hasonlóan három paramétert ad át neki. Az aktuális elemet, az indexét és magát a tömböt. Annyi a különbség, hogy ez egy új tömböt hoz létre kimenetként a callback függvény által visszatért érték alapján. Nézzünk is egy egyszerű példát:

var myNumbers = [4, 16, 64, 256],
    myRootNumbers = [];

for (var i = 0, _l = myNumbers.length; i < _l; i++) {
  myRootNumbers.push(Math.sqrt(myNumbers[i]));
}

Ezek után a myRootNumbers az eredeti tömbünk értékeinek négyzetgyökét fogja tartalmazni, azaz 2, 4, 8 és végül 16. Ennek egy picit egyszerűbb formája, ha használjuk a map metódust:

var myNumbers = [4, 16, 64, 256],

    myRootNumbers = myNumbers.map(function(item) {
      return Math.sqrt(item);
    });

De talán még szebb, ha egyből a Math.sqrt-t hívjuk meg, hiszen az is (első) paraméterként az értéket várja.

var myNumbers = [4, 16, 64, 256],

    myRootNumbers = myNumbers.map(Math.sqrt);

Lényegesen egyszerűbb, rövidebb és szebb 🙂

Array.filter

Nagyon szép és nagyon jó ez a map, de mi van, akkor ha nekem nem kell minden elem. Sőt nem is akarok műveletet végezni rajta, csak simán leszűrni adott értékeket.

var myNumbers = [4, -16, 3, -4, 5, 6, 2, -5, -10],
    myNegativeNumbers = [];

for (var i = 0, _l = myNumbers.length; i < _l; i++) {
  if (myNumbers[i] < 0) {
    myNegativeNumbers.push(myNumbers[i]);
  }
}

Mostmár szépen le tudtuk szelektálni a negatív számokat. De miért szenvednénk ilyen hosszan, ha a filter metódus tud nekünk ebben segíteni. Szintén egy callback függvényt vár paraméterként és a jól megszokott érték, index, tömb hármassal hívja meg azt. Ez hasonlóan a map-hez végigmegy az elemeket és kimenetnek felépít egy tömböt, de csak azokból az elemekből, amiknék a callback igazként tért vissza.

var myNumbers = [4, -16, 3, -4, 5, 6, 2, -5, -10],
    myNegativeNumbers = myNumbers.filter(function() {
      return (myNumbers[i] < 0);
    });

Sokkal, de sokkal szebb 🙂

Array.every

Ez egy érdekes függvény. Ennek a kimenete igaz vagy hamis. A jól megszokott callback, ami megkapja a három paramétert, használat van itt is érvényben. Sőt nagyon hasonló a filter-hez, annyi különbséggel, hogy nem a true visszatérésű elemeleket pakolja be a kimeneti tömbbe.

Ha minden (every) callback igaz értékkel tért vissza, akkor igaz, minden más esetben hasmis lesz a kimeneti érték. Bár a lenti példa elég bugyuta, de arra jó, hogy látható legyen a működése.

var me = { "id": 9 },
var messages = [
  { "recipient": 9, "content": "Üzenet 1" },
  { "recipient": 9, "content": "Üzenet 2" },
  { "recipient": 7, "content": "Üzenet 3" },
  { "recipient": 9, "content": "Üzenet 4" }
];

var eachMessageForMe = messages.every(function(message) {
  return (message.recipient === me.id);
});
// return value: false

Ez a szépség nekünk elment az eachMessageForMe változóba, hogy minden üzenet nekem szól-e vagy sem. Egyszerű false értékkel fog visszatérni, lévén van egy ami hamisat ad.

Array.some

A neve is jól mutatja és tulajdonképpen lehetne együtt említeni az every metódussal is, mert ez akkor tér vissza igazzal, ha van olyan elem, amire igaz a callback tartalma.

var me = { "id": 9 },
var messages = [
  { "recipient": 9, "content": "Üzenet 1" },
  { "recipient": 9, "content": "Üzenet 2" },
  { "recipient": 7, "content": "Üzenet 3" },
  { "recipient": 9, "content": "Üzenet 4" }
];

var mentioned = messages.some(function(message) {
  return (message.recipient === me.id);
});
// return value: true

Hiszen van olyan érték, amire igaz. Viszont ígértem, hogy a forEach megoldáshoz egy break működést is mutatok. Ezt pontosan a some-al lehet megcsinálni, mivel a ez a metódus az első igaznál megáll.

var myNumbers = [4, 16, 3, -4, 5, 6, 2, -5, -10],

var isInvalid = false;
for (var i = 0, _l = myNumbers.length; i < _l; i++) {
  if (myNumbers[i] < 0) {
    isInvalid = true;
    break;
  }
  // Csinálhatunk egyéb mást is még...
}

if (isInvalid) {
  alert("Negatív számot nem fogadunk el...");
}

Ezt egyszerűen a some felhasználásával meg tudjuk valósítani, csak annyi a dolgunk, hogy mindig false-al térünk vissza és amikor meg szeretnénk állítani a folyamatot, akkor visszatérünk egy true értékkel.

var myNumbers = [4, 16, 3, -4, 5, 6, 2, -5, -10],

var isInvalid = myNumbers.some(function(value) {
  if (value < 0) {
    return true;
  }
  // Csinálhatunk egyéb mást is még...
  return false;
});

if (isInvalid) {
  alert("Negatív számot nem fogadunk el...");
}

Vége?

Nagyon sok metódus van, amit az emberek nem ismernek, mert gyorsan logikával (nagyon helyesen) megalkottak az általuk ismert módokon, de vajon az a legoptimálisabb időben, energiában vagy processzorban? Te milyen egyéb olyan megoldásokat használsz, amit ritkán látsz mások munkáiban? Objektumokra, számokta, tesztekre vagy bármi másra.

Kapcsolódó cikkek:

Ezért nem szeretem a jQuery-t

Mikor szóba kerül a jQuery, akkor majdnem mindig megkérdezik, hogy miért nem szeretem. Sok oka van, de a teljesítmény talán a legszembetűnőbb. Mivel a helyszínen sokszor nem tudom megmutatni, így nem is hisznek nekem, hogy mennyivel lassab egy-egy művelet vele.

Természetesen ez csak akkor jön ki, amikor valami nagyon nagy, főként kliens oldalon tevékenykedő kódot ír az ember. Sok könnyedséget ad, mert nagyon jól összeszedett. Még több öröm leli az embert, amikor talál valami plugin-t, ami pont kielégíti minden vágyát. A plugin meg amúgy is a rosszabbik fajta, de ezt most nem akarom elővenni, már csak azért sem, mert abban sokan egyetértettek velem, hogy a kiegészítő modulok nagy része nincs jól megírva.

Kód

Nézzünk is akkor egy gyors példát. Van egy div, amiben további kettő ezen mintára:

0

Írjuk át az item osztállyal rendelkező elemek tartalmát aszerint, hogy ezt kapjuk a végén:

1

Mi sem egyszerűbb ennél. Lekérdezzük az összes .item element, végighaladunk rajtuk, majd tartalmukat kicserélkül.

Nézzük sorra a jQuery, VanillaJs és természetesen egy bónusz vegyes kód, ami felhasználja mindkét kódot részben.

Hogy szó ne érjen beraktam még egyet a végén, ami nem a querySelectorAll metódust használja:

Hogyan mérjük?

Persze nekiállhatnánk írni egy új banchmark eszközt, de minek, ha már van. A Benchmark.js (v1.0.0) elég jól működik, jól konfigurálható és mindemellett a BestieJS része.

A logika egyszerű. Felsorakoztatjuk a kódrészeinket, majd szépen sorban lefuttatjuk őket, majd szépen elmerengünk az eredményen. Mikor ennek most nekikezdtem nem volt foglalmam róla, hogy mennyivel lassabbak vagy gyorsabbak az egyes kódrészek, de tudtam, hogy drasztikus lesz a különbség. Olyannyira az lett, hogy még én is meglepődtem.

Milyen gépről beszélünk

Persze ez nem mindegy. Aminél épp most ülök és amin nézem, az egy MacBook Pro. Mit tartalmaz? 2.6 GHz Intel Core i7 processzor, 8 GB 1600 MHz DDR3 memória. Google Chrome fut, mint böngésző és abból is a Version 28.0.1500.20 beta.

Természetesen ugyan ezen a gépen megnéztem más böngészőkkel is, de ezt majd lentebb látni lehet.

A mérés

Akkor mérjünk, hiszen ezért vagyunk itt. Miután leszedtük a Benchmark.js 1.0.0-ás verzióját, készíteni kellene egy oldalt, amin ezt leteszteljük.

És akkor az eredmények

Google Chrome (Version 28.0.1500.20 beta)

Start...
Vanilla x 868,471 ops/sec ±27.53% (75 runs sampled)
jQuery x 25,664 ops/sec ±6.36% (91 runs sampled)
jQuery with Vanilla x 233,890 ops/sec ±2.44% (90 runs sampled)
jQuery with Vanilla v2 x 31,845 ops/sec ±0.55% (96 runs sampled)
Vanilla old x 1,944,603 ops/sec ±0.68% (98 runs sampled)
Fastest is Vanilla old

Mozilla Firefox (21.0)

Start...
Vanilla x 360,292 ops/sec ±2.23% (89 runs sampled)
jQuery x 2,646 ops/sec ±1.52% (88 runs sampled)
jQuery with Vanilla x 11,772 ops/sec ±3.99% (88 runs sampled)
jQuery with Vanilla v2 x 3,572 ops/sec ±2.61% (85 runs sampled)
Vanilla old x 1,504,734 ops/sec ±6.73% (70 runs sampled)
Fastest is Vanilla old

Safari (Version 6.0.4 (8536.29.13))

Start...
Vanilla x 350,148 ops/sec ±6.72% (55 runs sampled)
jQuery x 20,689 ops/sec ±4.75% (61 runs sampled)
jQuery with Vanilla x 61,427 ops/sec ±4.71% (61 runs sampled)
jQuery with Vanilla v2 x 32,140 ops/sec ±3.68% (61 runs sampled)
Vanilla old x 1,652,603 ops/sec ±1.65% (64 runs sampled)
Fastest is Vanilla old

Értelmezés

Az ops/sec minél nagyobb annál jobb. Minden esetben jól látható, hogy a legygyorsabb a régi jól bevált getElementById és getElementsByClassName használata volt közel 2millió művelet másodpercenkénti sebességgel. Őt követte a querySelectorAll használata jóval kevesebb, de még mindig szép sebességet produkáló kódrész.

Ezek után jött az érdekes rész. jQuery három különböző használati mintával. Első esetben ugyebbár teljesen az ő függvényeit használtuk, így kiérdemelve a leglassabb díjat kicsit kevesebb mint 3ezer művelet másodpercenként. Hogy megnézzük mi is a gyorsabb és lassabb része, különszedtük és megnéztük, hogy milyen, ha csak az írást vagy csak az olvasást végzi a jQuery. Láthatóan ha csak a keresést végzi, akkor gyorsabb a lefutás, ezek szerint a DOM írás jQuery-vel jóval “drágább” művelet. A DOM írás amúgy is drágább, de jQuery-vel nagyon durván.

Kapcsolódó cikkek:

OpenSource, de miért?

A nyílt forrást (OpenSource) manapság azért szerencsére kezd elterjedni. Sokan még mindig félnek tőle, de egyre több cég nyitja meg szoftverének forrását. Vagy egy részét vagy egy régebbi verzióét. Amellett, hogy reklám, még haszna is van. A cikket +Laszlo Fazekas cikke inspirálta, Miért jó a nyílt forrás?! címmel. A cikk jól összeszedi, hogy gazdasági szempontból miért érheti meg forráskódunk megnyitása. A cikk viszont kevésbé tér ki a programozó világban betöltött jelentős előnyére, mégpedig arra, hogy miért éri meg egy nyílt forrású kódon segédkezni, miért éri meg saját otthoni fejlesztéseinket publikálni. Az ugye majdnemhogy egyértelmű, hogy senki se számíthat milliós támogatásra, ha csinál valami egyszerű kis programkönyvtárat vagy javít egy hibát valaki más kódjában. Akkor miért?

(tovább…)

Kapcsolódó cikkek:

Pár hasznos könyv (1. felvonás)

Rendszeresen fogok könyveket ajánlani, mert azok igencsak hasznosak. Ha valaki tanulni, akar, akkor az elérhető könyvek listája talán az egyik leghasznosabb dolog. Mivel én nem preferálom a “warez” dolgokat, így természetesen ár érték arányt is nézek mindig. Volt már példa arra, hogy egy könyv nem volt rossz, de jó sem, ha az árát nézem. Ezen oknál fogva szépen elkezdem kigyűjteni ide azokat a könyveket, melyek lényegesen hozzájárultak a fejlődésemhez vagy épp másokéhoz.

(tovább…)

Kapcsolódó cikkek: