NetAcademia

A legjobbakat tanítjuk!

Az első gólya :)

2018. augusztus 01. 13:16 - Plesz Gábor

Van egy rövid, de lendületes nekifutásunk annak érdekében, hogy a C# nyelvet és a programozást megmutassuk az érdeklődők számára. Menet közben jött az ötlet, hogy jó lenne még több szereplőt bevonni a történetbe, hátha segít meggyőzni a bizonytalanokat, ha programozni szeretnének tanulni, akkor bizony ez a C# útvonal, amin megyünk, megfelelő.

Jó hír, hogy a felkérésre érkeznek a válaszok!

Az első mindjárt a Geomant-tól, ahol csevegőrobotot is és C# nyelvet is használnak minden egyes nap. Így a következő C# lenyűgöző alkalom számára irodájuk igazán barátságos környezetet nyújt majd nekünk.

Örömmel jelentem be tehát a jövő hétfői időpontot, 16:30-tól várunk szeretettel minden érdeklődőt ezen a meetup-on, ahol 17:00-től a szokásainknak megfelelően hajszálpontosan kezdődik az élő tartalom, így mindenkit kérünk, hogy 16:45-ig érkezzen meg.

Szólj hozzá!

Gyorsítsuk fel az oktatást a tízszeresére!

2018. július 05. 10:15 - Fóti Marcell

time.jpg

Az időből mindenki egyforma mértékben részesedik. Minden egyes munkanap 24 órából áll. 

Egyesek mégis többre viszik, mint mások. 

Egyes vállalatok mégis tízszeres eredményt érnek el, mint mások.

Hogyan?

A titok nyitja az idő helyes kihasználásában rejlik. Tanulás esetén is.

Ma már az emberek nem képesek megnézni egy 70-es években készült filmet, annyira borzalmasan lassú.

Ugyanez a helyzet az oktatásban is. A hagyományos tantermi oktatás - egy Monthy Python-idézettel élve - complete waste of time.

Gyorsítsuk fel az oktatást a tízszeresére!

A hagyományos tantermi oktatásban rengeteg időt pazarolnak el üres fecsegésre, szaknyelven szólva: vattázásra. A 40 órát ki kell tölteni! Nemde? Nem!

Az első lépés az oktatás megreformálásában az időpocsékolások megszüntetése. Má már senki nem ér rá:

  • másfél órát utazni egy tanfolyamért
  • 30 percen keresztül a többi résztvevő bemutatkozását hallgatni
  • üres fecsegésként meghallgatni egy órában, miről fog szólni a tanfolyam
  • további süketelést hallgatni arról, hogyan volt ez régebben
  • további elméleti süketelést hallgatni póverpointozás közben
  • a tanfolyam tempóját kivárni

A tanulás akkor hatékony, ha:

  • nem tartalmaz üres fecsegést, süketelést, sallangokat, vattázást
  • ütemesen halad, de bármikor megállítható
  • tetszőleges időpontban, akár holt időben végezhető (buszon/vonaton)
  • a tempója szabadon megválasztható: kétszeres sebességtől a kikockázásig
  • akárhányszor átismételhető
  • gyakorlatorientált

Emellett az sem baj, ha a rétestésztát kicsi rétesekre vágjuk. Ez lehetővé teszi, hogy mindenki annyit, és azt egyen, amire valóban szüksége van. Minek végigülni 600 óra fecsegést egy olyan témáról, ami a kisujjadban van? Elég neked az újdonság, a lényeg!

Tudom-tudom, még mi sem tartunk itt. De a gondolat megvan. Már csak meg kell valósítani.

Az újraindult https://tudastar.netacademia.hu/ egy erre irányuló kísérlet. Csírája.

Mi a NetAcademiánál azon dolgozunk, hogy az oktatás hatékonyságát a tízszeresére növeljük!

Szólj hozzá!

Mondom is: miért nálunk tanulj!

2018. június 29. 12:56 - Plesz Gábor

Korábban a C# nyelv és a .NET Core környezet néhány előnyéről írtam, csak úgy általánosságban. Tettem ezt azért, hogy mindenképpen vegyétek figyelembe, mint jó választást - leginkább akkor, ha most kezdenétek tanulni egy programozási nyelvet.

Ezúttal inkább arról írok, hogy miért hozzánk gyere C#-ot tanulni, ha érdekel a nyelv?

Mi a NetAcadémiánál hosszú évek óta folyamatosan fejlesztjük a módját, hogyan lehet könnyebbé tenni a beavatást az újak számára.

A kérdés egyből adódik: miért kéne könnyebbé tenni bármit is?

Nos, a válasz majdnem ilyen egyszerű: nagyon, nagyon, nagyon nehéz elkezdeni programozni tanulni. Sok mindent kell elsajátítani ahhoz, hogy az alapfogalmakat megértsük. És ekkor még csak ott vagyunk, hogy a kérdéseket megérthetjük. Órák telhetnek úgy el, hogy semmi működő vagy használható dolog nem készült el a kezünk által, és még mindig csak az alapozást gyűrjük.

Persze ebben nincs semmi meglepő, általában így néz ki egy összetett világ bonyolult feladatok megoldására való eszközeinek a megismerése. Ahhoz, hogy ezt a belépési gátat megmásszuk kell még legyen elég időnk, eszközünk, motivációnk, és a többi, és a többi, ami mind, mind szükséges.

Ezért mi itt a NetAcademiánál mutatunk egy jobb utat.

Először is, a tanfolyamainkon kivétel nélkül készítünk valami használhatót. Egyszerűen úgy épülnek fel, hogy a feladat valaminek a létrehozása.

Közbevetés. Én személy szerint ezzel kivételesen szerencsés helyzetben vagyok, már ugye a C# nyelvvel és a .NET környezettel. Ugyanis a C# egyaránt lehetőséget biztosít néhány óra alatt Raspberry PI alkalmazást, csevegőrobotot, kártyajátékot windows-ra, vagy webszerveres alkalmazást készíteni. Aki egy alkalmat végignézett már nálunk, az tudja ezt.

Sajnos már az egy alkalom is több órás, amihez a hallgatóinknak még mindig meg kell szervezni az időt, energiát, érdeklődést, és így tovább. Még csak egyetlen alkalomról beszélünk, ebből azért kell jópár, míg az ember beletanul a dolgokba.

Itt felmerül még egy kérdés: Hogy tudnánk ezt a csomagot egy kicsit könnyebbé tenni?

Másodszor is, hát úgy, hogy felvétel készül minden tanfolyamunkból, így tetszőlegesen újranézhető egy-egy alkalom. Ezzel biztosítható az, hogy akár részletekben is megnézhető legyen az anyag.

Harmadszor, a tanfolyamon készült forráskódot lépésenként feltöltöm a GitHub-ra, így az egy lépésben készült kód külön csomagban megnézhető, ezzel is csökkentve az egyszerre feldolgozandó ismeret csomag méretét.

Ráadás. Az elmúlt időszakban a videóinkat is úgy daraboltam, hogy minden lépés egy-egy külön videóba kerül. Vagyis az egyszerre megértendő, gyakorolandó és otthon reprodukálandó anyag általában 10-30 perces részekben a rendelkezésre áll, a hozzá tartozó programkóddal együtt.

Vagyis: nem kell többé egy fél napot vagy ami még nehezebb, egy egész napot szabaddá tenni a tanuláshoz!

Ha valakinek van 10-20-30 perce, már tehet egy lépést az anyaggal. Megnézheti hazafelé a buszra várva, csak hogy tudja, miről lesz szó. Majd otthon még egyszer, közben nézve a hozzá tartozó forráskódot. Majd még egyszer, úgy, hogy maga is írja a kódot, saját kézzel elkészítve az adott lépést. Ezt, ha szükséges, a hallgatóink addig ismételhetik, amíg az anyagot teljesen el nem sajátították. Kis pici csomagokban, ezeket a csomagokat már  bárki megértheti.

Nagyon sok jó visszajelzést kaptunk a módszerrel kapcsolatosan, és most azért álltam elő ezekkel a gondolatokkal, hogy jelezzem: ha érdekel a programozás, akkor most tényleg bele tudsz vágni. Vagy ha ismersz olyat, aki érdeklődik, de a belépési küszöb miatt aggódik, akkor szólj neki. Nézzétek meg nálunk a C# útvonalat, tegyetek egy próbát. Az első három tanfolyam az útvonalból véget ért, van ingyenes tanfolyami rész, senkinek sem kell zsákbamacskát vennie.

Tovább is van, mondjam még? :)

Vannak fejvadászok és cégek, akik szívesen találkoznának a hallgatóinkkal, alkalmasság esetén állást is kínálva nekik. Ugye, ugye, az informatikushiány...
Ne tagadjuk el, ehhez egy remek aduász, ha a tanfolyamsorozat végén a hallgató megszerzi a NetAcademia Certificate-et.

Mivel az előzetesen tervezett ingyenes sorozatunk a C# lenyűgöző tanfolyamból véget ért, és sok pozitív visszajelzést és ötletet kaptunk a folytatásra vonatkozóan, tervezzük további alkalmak kiírását is.

Ehhez most az érdeklődő cégek oldaláról szeretnék barátokat gyűjteni: ha használtok C#-ot (azt már nem is írom, hogy esetleg csevegőrobot fejlesztésben is gondolkodtok, de ez utóbbi egyáltalán nem feltétel), büszkék vagytok a munkátokra és szívesen biztosítanátok helyet egy élő felvételnek, valamint a helyszínen megjelenő 10-20-30 érdeklődőnek frissítővel és pogácsával, akkor itt az idő, kérem jelezzétek felénk.

Nagy örömmel mutatnánk be a C# hatékonyságát élőben olyan cégeknél, akik értő módon használják azt. Az előnyök egy ilyen eseményen azt hiszem minden résztvevő számára egyértelműek.

És ha bármi kérdés adódik, írjatok!

Szólj hozzá!

Mondom is, miért C#

2018. május 19. 18:11 - Plesz Gábor

Tehát, szóval. Miért is érdemes C#-ban programozni?

Csak nagyon röviden: mert szinte minden területen, kis belépési kültséggel, azonnal működő prototípust tudunk építeni, és a határ majdnem a csillagos ég. Ráadásul a tudáshoz való hozzáférés gyakorlatilag korlátlan.

Persze, hogy mindjárt mondok példákat is, de előbb megismétlem az eddigieket kicsit hosszabban:

Tegyük fel, hogy programozni szeretnél, és azt a nyelvet keresed, amin

a.) Windows-ra,
b.) Linuxra,
c.) iOS-re,
d.) Androidra,
e.) OSX-re

1. ) szerver
2. ) desktop
3. ) kliens
4. ) mobil
5. ) 2D/3D játék

alkalmazásokat írhatsz akár évtizedekig egy irányba haladva, nagy törések nélkül. Majd miután beletanultál dolgozni is szeretnél vele.

Akkor az a helyzet, hogy egyről beszélünk, hát ezért CSharp.

A nyelvet 2000-ben mutatták be, eleve úgy indult, hogy a Java-hoz hasonlóan mindenhol fog majd futni, de az MS Windows környzeten kívül nagyon lassan haladt a fejlődése, mivel a Microsoft a Windows-ra koncentrálta erőit. Óriási áttörés történt viszont ebben az elmúlt években, a Xamarin megvásárlásával és a házon belüli ASP.NET "lázadással" a nyílt forráskód irányába. Immár a felsorolt esetekben teljes értékű, első osztályú polgára a fejlesztési világnak.

Tényleg, mielőtt belevágunk: mi van a teljesítménnyel?

Tudod, Microsoft..., meg a Windows... Hát, hogy is mondjam.

Ebből a legújabb TechEmpower Framework Benchmarkból egyértelműen kiderül, az ASP.NET Core környezet, amivel a szerveroldalon dolgozunk, másodpercenként majdnem 7 millió kérést szolgált ki a plain text versenyben, a verseny szabvány futtatókörnyezetében. Erre mondják, hogy a teljesítménymérések alfájában.

Ezzel a leggyorsabb versenyző 98.1%-os teljesítményét hozta. Vegyük észre, hogy előtte az eredménylistán hiába keressük a nagy frameworköket. Tényleg, aki a listán hallott ebben a kategóriában az ASP.NET Core előtt végző versenyzőkről, és látott már valamelyik használatával rendes fejlesztést, NetAcademia bögrét kap.

A teljesítmény tehát köszöni szépen, alakul, alakulgat.

Akkor nézzük ezt a sok környezetet, mondjuk manapság egy kikerülhetetlen dolog az IoT, és ennek egyik kiváló csillaga, a Raspberry PI. Jó. Akkor mondjuk ezzel mi van?

Az van, hogy az elmúlt napokban kétszer is belefutottam, egyszer Hanselmann írt egy szívhezszóló cikket arról, hogy is lehet Docker segítségével Raspberry PI (ARM) architektúrán C# huszárkodni.

Aztán pedig jelezte, hogy most lesz nemsokára (azóta már volt) a Twitch-en egy 9 órás igyenes demonstráció/kódolási maraton/bemutató workshop, ahol egyebek mellett Docker segítségével C# nyelven Raspberry PI-t is programoznak.

Na, ugye.

De miért mondtam mindezt itt el?

Mert az a helyzet, hogy mi itt Magyarországon olyan nagyon nem vagyunk lemaradva.

Mivel ezek előtt, 2018. április 23-án 15:00-18:00 között az előző NetAcademia meetup-on ki nem találnád,
de C# nyelven Docker segítségével a Raspberry PI ledjét villogtattuk. Az eseményről készített videók ingyenesen elérhetőek mindenkinek, regisztráció után.

A jegyzőkönyv kedvéért:

  • A következő alkalom 2018. június 04-én lesz, amikoris a saját gépünkön futó csevegőrobotból fogjuk ezt a kódot használni.
  • Aztán pedig 2018. június 25-én kitesszük az egészet az Internetre, és akár Facebook Messengerből vagy Skype-ból is élvezhetjük munkánk gyümölcsét.

Azt pedig már el sem mondom, hogy a hónap elején elindult a NetAcademia Certified Junior C# fejlesztő útvonal, ha valaki hivatásszerűen szeretné megismerni a C# világát.

Régebbi C# motorosoknak pedig a szintén most indult NetAcademia Certified Unity Developer 
útvonalról nem beszélek bővebben, ami akár az előző után is elvégezhető mivel a tanfolyamokról szokásosan visszanézhető videó készül, a könnyebb elmélyülés érdekében.

Szóval tényleg csak elhatározás kérdése most rendes C# programozóvá válni:)

Azzal szeretném megköszönni, hogy idáig olvastál, hogy ha van valami ötleted, hogy mit lenne jó megvalósítani a következő NetAcademia meetup-on/meetup sorozaton, akkor vagy kommentben, vagy e-mail-en (plesz.gabor@netacademia.hu) küldd el nekem.

Ajándékként azt tudom felajánlani, hogy ha nyersz, akkor -egy bögre mellett- a soron következő meetup-on -akár együtt is, ha van hozzá kedved- megcsináljuk.

46 komment

önkéntes IT angyal kerestetik :)

2018. május 08. 14:55 - Plesz Gábor

A NetAcademia blog-on az elmúlt hónapokban folytatásokban lefordítottuk a következő cikkgyűjteményt: The Twelve-Factor App. Ez egy kikristályosodott szabályrendszer arról, hogyan érdemes alkalmazást fejleszteni és üzemeltetni a 21. században. Azért lehet érdekes, mert a szerzők a Heroku-nál több százezer alkalmazás üzemeltetésében és több száz alkalmazás fejlesztésében vettek részt, így komoly tapasztalattal rendelkeznek.

Tapasztalatuk rengeteg féle alkalmazás hosszú éveken át történő fejlesztéséből, telepítéséből és üzemeltetéséből származik. Meglátásom szerint minden szava aranyat ér.

Ír például a szoftver-pusztulás fogalmáról, ami konyhanyelven szólva annyit jelent, hogy egy változatlan alkalmazás az idő múlásával a szükségszerűen változó környzetben (új OS kiadások, patch-ek, új hardverre költözés, új könyvtárba költöztetés, stb. stb.) évek vagy évtizedek alatt, egy idő után korszerűtlen, majd elavult, majd működésképtelen lesz. Mivel ez elkerülhetetlen, ezért az egy fontos kérdés, hogy lehet-e, és ha igen, akkor mit lehet tenni már a fejlesztés előtt/alatt, hogy ez a hatás lehetőleg minél hosszabb idő alatt alakuljon ki? Nagyon nem mindegy, hogy évekről vagy évtizedekről beszélünk ugyanis.

Ez csak egy példa volt, hogy ez a 12 szempont milyen meghatározó lehet egy alkalmazás életciklusában. Sok-sok nemtriviális gondolat van benne, és egy jól járható irányt jelentenek a jövőre nézve. Tekinthetünk rá szabványként is: az így felépített alkalmazás a teljes életciklusa során jól meghatározott jellemzőkkel rendelkezik; olyan egyértelműen pozitív tulajdonságokkal, amikre aztán számítani is lehet ez alatt az életciklus alatt.

A szempontok fontosságát a fordításban a tényező kifejezés meghagyásával is szerettem volna hangsúlyozni: a szempontok egyenként is fontosak, de a végeredményt tekintve szorzótényezőként viselkedve egymás hatását is sokszorozzák. Vagy akár lenullázzák.

Ezért a pontos megértésük elengedhetetlen, és persze az is, hogy terjesszük az igét. Én magam nem vagyok natív angol, ezért aztán lefordítottam az anyanyelvemre, hogy tényleg pontosan értsem a gondolatokat.

És hogy miért írom most ezt itt? Máris mondom.

A fordítást elküldtem a szerzőknek, hogy nekik is meglegyen a magyar fordítás. Ha valaki esetleg nem a NetAcademia blogon fut bele, hanem az eredetit nézi, talán könnyebbséget jelent, ha ott van magyar fordítás.

Ahhoz, viszont, hogy a fordítás kikerüljön a 12factor.net oldalra, kell még legalább egy független szerkesztő/ellenőrző/áttekintő személy, aki a fordításom ellenőrzi, sajnálatos módon natív magyar kolléga náluk ebben a csoportban nem dolgozik.

Tehát. Aki a github-on eligazodik, tud angolul és van kedve önkéntes munkával a magyar nyelvű IT közösséget szolgálni, kérem nézzen rá a pull request-emre, és csináljon egy review-t. Bármilyen visszajelzésnek örülök!

Szólj hozzá!
Címkék: 12FactorApp

Gyakori programozási hibák #1 - vigyázz, makrók! (C, C++)

2018. április 17. 10:09 - bardóczi ákos

A posztsorozatban olyan tipikus programozási, konkrétabban kódolási hibákat, később szemantikai hibákat vesézek ki, amikkel szinte biztos, hogy szembesül az, akinek a C vagy a C++ az első programozási nyelve. A felsorolás persze szubjektív, a számomra legemlékezetesebb hibákat tárgyaljam, de többször puskázok Dennis Ritchie,  Bjarne Stroustrup alapműveire, amiben fel is hívják a figyelmet egy-egy hibalehetőségre, ezen kívül Koenig C csapdák és buktatók, és Dewhurst C++ hibaelhárító című könyeire.
A makró szigorúan nézve nem is a programozási nyelv része, hanem csak a fejlesztő munkáját segítő eszköz, amikor a fordító egyszerűsítve a fejlesztő által makróban meghatározott szöveggel cseréli le a forráskód összes, makróval hivatkozott részét.
Ennél egyszerűbb nem is lehetne, ugye? Természetesen ebben is van hibalehetőség az igen szigorú szintaxis miatt, ráadásul esetenként éppen olyan hibát eredményez, ami miatt a tanonc a hibát teljesen máshol kezdi el keresni, mint ahol az ténylegesen van, függően a makróban meghatározott szövegtől. Hogy még bonyolultabb legyen, esetenként implementációfüggő, hogy a fordító hogyan kezelje a makrókat.
A makró meghatározásának általános sémája:
#define makro_neve makro_erteke
Ami viszont nagyon nem mellékes, hogy a fordító véresen komolyan veszi, hogy a #define után egy szóközzel van elválasztva a makró neve és attól pontosan egy szóközzel van elválasztva a makró értéke, ami már mellékes, hogy mennyi szóközt tartalmaz, elvben, de arról később.
Vegyük az alábbi példát:
#define hozzaadas (szam) ((a)+1)
Ha nem tudjuk az előbb ismertetett ökölszabályt, akkor azt hihetnénk, hogy a
hozzaadas (szam)
előfordulási helyén majd mindenhol az ((a)+1)-t építi be a fordító, valójában viszont ha a makrót úgy kezeljük, mintha függvény lenne a behívás helyén valami ilyesmi épülne be:
(szam) ((a)+1)
Ami teljesen világos, hogy mást csinál, ráadásul ez itt egy nagyon egyszerű eset.
A C-nél a C++nál gyorsan hozzá lehet szokni, hogy a forráskódban a szóköz gyakran csak szellősebbé teszi a forráskódot, ez a makróknál nem így van.
Szólj hozzá!

Agyagtáblától az Evernote-ig

2018. április 05. 15:16 - bardóczi ákos

digitalis_irastudas.jpgAlighanem nagyon sokan találkoztak már két szélsőséges hozzáállással, ha okoseszközökről, productivity toolokról, például jegyzetkészítésről vagy egy tudományos publikáció megírásáról van szó. Az egyik, a "go paperless", ami szerint mivel mindenre van valamilyen frappáns, elérhető informatikai megoldás, egy idő után egyáltalán nem lesz szükség papírra és hagyományos írószerekre, mivel mindent a gépen tárolunk majd valamilyen módon, a mostani trend szerint a felhőben. A másik szélsőséget azok képviselik, akik esetleg nincsenek is tudatában annak, hogy a megfelelően megválasztott, korszerű, csoportmunkát támogató eszközök használatával mennyi időt, energiát és természetesen pénzt lehetne összesen megspórolni.

A következő posztban nem leszek objektív, nem is törekszem rá, inkább azzal kapcsolatban próbálok adni egy áttekintést, hogy miért lenne célszerű mindenkinek jóba lennie az olyan szolgáltatásokkal is, amik a felhasználónak valamilyen, esetleg több évtizedes megszokását törik meg lényegében, ezek közül ebben a posztban az egyszerű jegyzetelő appokra szorítkozok.

don_tapscott_wikinomia.jpgAhogy a szépnevű piaci elemző cégek jelentései, úgy egy-egy korszak meghatározó szakkönyvei is tartalmaztak olyan jóslatokat a jövővel kapcsolatban, amik ha megvalósultak, lehetett hivatkozni rájuk, hogy már mikor sikerült megjósolni, ha pedig nem valósultak meg, mindenki elfelejti.
Don Tapscott 2006-ban megjelent Wikinómia
 című könyvében eléggé konkrétan érvelt amellett, hogy 2010-re gyakorlatilag megszűnik a print könyvek piaca. Ehhez képest a print könyvek piaca nemhogy eltűnt volna, hanem még kis mértékben növekedett is, ráadásul úgy, hogy közben megrázta a világot egy kiadós válság. 

Bill Gates a 2002-ben kiadott, Üzlet a gondolat sebességével könyvében arról írt, hogy a Microsoft lényegében még kiskorában is, hasonlóan a többi tech céghez, elképesztő mennyiségű pénzt fordított nyomtatásra, majd kigondolta, hogy az összes, csak papír alapon létező dokumentumtípusból vigyenek be egy-egy példányt az irodájába. Az eredmény minimum elképesztő volt: több ezer, ha nem több tízezer különböző dokumentumot használt a Microsoft, amire egészen addig vagy nem volt megfelelő informatikai megoldás vagy nem jutott eszükbe használni. Ekkor a MS akkori feje lényegében kísérleti jelleggel kitalálta, hogy a mammutvállalatnál amilyen gyorsan csak lehet, de térjenek át a papírmentesebb adminisztrációra, ami sikerült is. Megjegyzem, Bill Gates sosem tolta túl a manapság divatos "go paperless" őrületet, egyszerűen azt vitték gépre, amit célszerűbb volt gépen kezelni.
Bill Gates a megállapításaival tényleg meghaladta a korát, több olyan trendet és eseményt is bejósolt, ami már-már sci-finek tűnt az ezredforduló táján, mára pedig mindennapi életünk részévé vált, legyen ez bármilyen közhelyes is.

Hogy mennyire jósolt pontosan? A Gates-kötet több kapcsolódó megállapítása azért is különösen érdekes, mert azt jóval később kvantitatív adatokkal is alátámasztották több pszichológiai kísérletben. Ezek közül az egyik, hogy ami 20-30 oldalnál hosszabb, azt a felhasználók többsége, alighanem kultúrától, így nyelvtől függetlenül inkább print formában, esetleg ebookon olvassa el, ha teheti, míg ennél rövidebb dokumentumok kényelmesen értelmezhetők anélkül, hogy kinyomtatnánk.

Szorosan kapcsolódik a témához az a néhány évvel ezelőtti, USA-beli elit egyetemen elvégzett kísérlet, amiben arra keresték a választ kutatók, hogy azok jegyzik meg hatékonyabban az előadáson elhangzottakat, akik semmilyen papíralapú eszközt nem használnak vagy éppen azok, akik hagyományos módon jegyzetelnek. Az eredmény hatalmas pofon volt - na jó, annak kellett volna lennie - azoknak, akik úgy gondolják, hogy mára az összes papíralapú eszköz felváltható laptoppal, tablettel vagy okoskütyüvel.
Annak ellenére, hogy már bőven rendelkezésre állnak olyan, könnyen elérhető eszközök és szolgáltatások, amik alkalmasak arra, hogy a felhasználónak elvben csak a jegyzetelésre kelljen figyelnie és az egész a papír alapú jegyzetelés rendelkezésre állásával összemérhetően működjön, határozottan kevesebbet jegyeztek meg az előadó által elmondottakból a teljesen kütyüre kattant, azaz papíralapú jegyzetet nem használó hallgatók a 2016-os tanulmány szerint.

A kutatók persze többféle lehetséges magyarázattal is előálltak, amivel igencsak illik kalkulálnia az ICT-piacnak. Az egyik legfrappánsabb magyarázat nem az, hogy a hallgatók életük első, tanulási drillek szempontjából kritikus felét még okoskütyük nélkül töltötték, azaz nem szocializálódtak hozzá eléggé. A legvalószínűbb ok, akkor is eléggé jelentős szerepet kap a kinesztetikus memória és az ehhez kapcsolódó kognitív folyamatok a tanulás közben, ha nem versenytáncot tanul valaki.


tanulas_pszichologiaja.jpgPongyolán fogalmazva a kinesztetikus memóriához sorolható, ahogy jegyzetelés közben kézmozgással formáljuk a betűket, strukturáljuk a szöveget, lapozunk, ha betelt az oldal és így tovább. Nem meglepő módon egy írott szöveganyag megtanulásánál ugyancsak használatban van a kinesztetikus memória, azaz a papír tapintása, a lapozással járó mozdulatok és még ki tudja, hogy mi, amire nem gondolnánk, amikor olvasás alapján történő tanulásról van szó. Martin Schuster Bevezetés a tanulás lélektanába című könyvében pedig arról ír, hogy a legjobb teljesítményt elérő hallgatóknál általánosan megfigyelhető volt, hogy egy könyvből való tanuláskor egyszerűen ügyesebben bántak a szöveg aláhúzásával vagy kiemelésével, mint a kevésbé sikeresek. 
Ki kell, hogy ábrándítsam azokat, akik úgy gondolják, hogy hamarosan már csak-csak elérkezik a paperless-kor. Az előző bekezdésben leírt kísérlet legvalószínűbb magyarázata szerint azok, akik csak tabletet vagy laptopot használtak, sokkal kevésbé használták a kinesztetikus memóriájukat. Igaz ugyan, hogy a tableten is kell koppintani, húzni, scrollolni és így tovább, egyszerűen sokkal kisebb variabilitást enged meg ahhoz képest, amikor koordinált kézmozgással és nem egyszerű érintgetéssel kell valamit lejegyezni, az pedig nem világos, hogy ha valaki úgy tanul meg írni és olvasni, hogy egész életében csak koppintgat és scrollol, ugyanolyan hatékony lesz vagy a finommozgások szerepe sokkal nagyobb.

A nagy helyzet, hogy máig vannak esetek, igaz, egyre ritkábban, amiket egyszerűen az adott szituációban praktikusabb papírcetlire feljegyezni, ha pedig szükség van a gépen való tárolására, arra ott az OCR, ha ez valami miatt nem opció, akkor a feljegyzés egyszerű lefotózása.
Kis szinesként itt megjegyzem, a magam részéről azért is tartom megmosolyogtató hülyeségnek a teljesen paperless világ utópiáját, mivel bizony-bizony, van nem egy olyan szakkönyvtár és levéltár Európában is, ahol a biztonsági előírások miatt írásos feljegyzés készíthető, de mindenféle kütyü használata tilos, azaz amivel lehetne fotózni...

Szó sincs róla, hogy az új eszközöket felváltanák a régieket, sokkal inkább arról, hogy értelmesen használva hatékonyabbá teszik a munkát, az ICT-játékosok hardver- és szoftver-oldalon egyaránt, mármint a rátermettebbek igyekszenek olyan megoldásokkal előállni, amik a régi és új módszereket ötvözik. Így például az ebook olvasók egy része nem bocsát ki fényt, de a hozzá tartozó tollal lehet a dokumentumban aláhúzni, kiemelni. Ugyanakkor nyilván elvárás, hogy egy jegyzetelő szolgáltatásban minél kisebb valószínűséggel forduljon elő olyan, hogy egy dokumentum elszálljon vagy olyan adatvesztés történjen, ami papír alapú eszközök esetén nem. Ahogy az is elvárás, hogy a szolgáltatás UX-szempontból legyen annyira letisztult, hogy tényleg csak az írásra kelljen figyelni. Ideális esetben az összes többi lehetséges szempont csak ezeket követi fontosságában.
Amikor legutóbb egy kurzust tartottam olyan témában, ahol a bemutatott technikák jellegéből adódóan fontos, hogy minél hatékonyabban dokumentáljuk, amit csinálunk, rövid ideig feladta a leckét az a kérdés, hogy melyik szolgáltatást javasoljam. Ahol lényegében egy pontos jegyzőkönyv elkészítésére van szükség, amiben pontosan látszik, hogy ki, mikor, mit szerkesztett, az adatvesztést és adatszivárgást minimalizálni kell, komolyabb alkalmazások jöttek számításba, amikről egy későbbi posztban írok, most pedig maradok az egyszerű jegyzetelőknél, felvillantva annak előnyeit-hátrányait.

Világos, hogy egy jegyzetelőalkalmazás nem lehet olyan funkciógazdag, mint egy wordprocessor vagy klasszikus értelembe vett szövegszerkesztő, ha pedig mégis, akkor minden fícsört, ami esetlegesen elterelheti a figyelmet, el kell rejteni a motorháztető alá, ami komoly UI/UX-kihívás, de nem megoldhatatlan. Ezen kívül persze elvárjuk egy-egy ilyen megoldástól, hogy legyen elérhető minél többféle platformon és minden platformon legalább nagyjából ugyanúgy viselkedjen. Általánosságban elmondható, hogy a piac szinte egészét itt is egy-két maréknyi szereplő uralja, ezen kívül még vannak olyan szolgáltatások, amik teljesen ingyenesnek mondják magukat, ilyenkor nyilván számítani kell vele, hogy előbb vagy utóbb, de lekapcsolják a villanyt, mert közösségi finanszírozás vagy jól megválasztott üzleti modell nélkül hosszú távon nem tarthatók fenn.

0. A email postafiókod notesz mappája

Alighanem sokan nem gondolnak rá, de már a kimondottan régi levelezőrendszerekben is volt egy speciális, szöveges feljegyzésére alkalmas tároló, amit számos levelezőrendszerben a mai napig megtalálunk Notes vagy hasonló név alatt, ha például IMAP4-klienssel csatlakozunk hozzá.
Gyakorlatilag a leggyorsabb megoldás, ha például a gépünkről egy URL-t szeretnénk átküldeni a mobilunkra, más kérdés, hogy több esetben ezt a kommersz levelezőszolgáltatók kivezették és átszoktatták a felhasználói bázist például a saját noteszappjukra.

1. Microsoft OneNote

microsoft_onenote.png

A klasszikus hotmail-es, outlook.com-os levelezőkben egykor volt, már nincs notesz mappa a postafiókban, viszont a változtatással körülbelül egy időben jelent meg a Microsoft jól ismert jegyzetelőszolgáltatása. Függetlenül attól, hogy böngészőn, asztali gép vagy mobileszköz alkalmazásán keresztül érjük el, majdnem ugyanazt tudja. Ahogy jól nevelt jegyzetelőapphoz illik, folyamatosan figyeli, hogy mikor torpanunk meg a billentyűzésben és ésszerű időközönként menti a jegyzetet a háttérben.
Az alapértelmezés szerinti az a jegyzet, amin legutóbb dolgoztunk, de a jegyzetek külön noteszekbe és levelek alá csoportosíthatók. Szükség esetén elővarázsolhatóak egy-egy notesz korábbi időpontokban automatikusan mentett verziói a webes felületen keresztül, viszont például az OSX-es kliensen már nem. Ahogy az OSX-es kliens lehetőségei a windows-osétől is kissé eltérnek, régebbi tableten pedig az egész akár kimondottan lassú lehet.
A OneNote a legnormálisabb általános célú jegyzetelő lehetne, de az előző fogyatékossága mellett szembetűnhet, hogy ha egy jegyzetet törlünk, az nem egy törölt elemek számára fenntartott helyre kerül, hanem elvben végleg megsemmisül. Az újabb verziókat már felkészítették hangjegyzetek, szabadkézi rajz rögzítésére, kimondottan szövegszerkesztő-funkciók kerültek bele, ugyanakkor a törölt jegyzet nem varázsolható vissza.

2. Evernote

Míg a Onenote-tároló akkor keletkezik, amikor először használjuk a Microsoft-accountunkkal, az Evernote teljesen önálló, freemium szolgáltatás, amiben azok közül a funkciók közül, amikre idővel szükség is lesz, több hiányzik, így például a jegyzet korábbi verzióit csak a fizetős verzióban érhetjük el. A OneNote-tól eltérően az Evernote kliensprogramja - freemium használata esetén - egy accounthoz maximálisan két eszközön lehet telepítve, ha több helyről szeretnénk elérni, azt csak a webes belépést követően érhetjük el. Lomtár viszont van az ingyenes változatban is.
Ha van örök érvényű tapasztalat, hogy a freemiumot kínáló szolgáltatásoknak szinte mindegyike olyan módon van kialakítva, hogy idővel úgyis szükség lesz valamilyen funkcióra, ami viszont már csak a fizetős verzióban érhető el. A két eszközre való korlátozást akkor vezette be az Evernote, amikor már látszott, hogy ez nem veszélyezteti a piaci pozíciójukat, ugyan a megváltozott árazás az árérzékeny piacok esetén alighanem látszik is.
Az Evernote támogatja a kétlépcsős hitelesítést, amivel egyedüli azok közül az alkalmazások közt, amik kimondottan jegyzetelőalkalmazások és nem alkalmazáscsomag részei.

evernote.jpg
3. Apple Notes

Az általam közel tíz évig használt noteszalkalmazás majdnem tökéletes lenne arra a célra, amire kitalálták, de sok-sok év után gyakorlatilag maga az Apple nyírta ki hagyományos formájában, nem is akárhogy. A Notes egy Apple-fiókhoz kapcsolódó alapszolgáltatás volt, amiben éppen az volt a szerethető, hogy amit feljegyeztem a legújabb almás mobilomba, az ugyanúgy jelent meg a közel 10 éves iPhone 3GS-en, az OSX Notes appjában, az egyiken elvégzett változtatás pedig gyakorlatilag azonnal látszott a többi eszközön bármiféle ütközés nélkül. Aztán néhány évvel ezelőtt egy új főverzióra való áttéréskor teljesen új Notes appot kaptak a felhasználók, ennek QA-szempontból elképesztően kínos, csak éppen kisebb felhasználói bázist érintő hatásaival. Arra lettem figyelmes, hogy az OSX-en beírt jegyzeteket eléri a mobilom, de a mobilon beírt jegyzeteket a nem is különösebben régi OSX Notes appja már nem, az iPad hol-hol nem, amit persze előre nem jelentett be az Apple. Arra korábban is volt lehetőség, hogy a Notes app ne az Apple cloudjában tárolja és kezelje a jegyzeteket az AppleID-hez kapcsolódó tárhelyen, beállítható volt olyan email-fiók is erre, amire a 0. pontban utaltam. De a kompatibilitási problémát ez sem oldja meg. A Notes app legújabb verziója csillog-villog, ha viszont régebbi eszközöknél próbáljuk meg beállítani, hogy a jegyzeteket például a GoogleMail-fiókból húzza elő, beállítás ide vagy oda, egyszerűen nem fog működni. A probléma nem érinti azokat, akik mindig a legújabb Apple-eszközt használják, viszont akik addig használnak egy-egy almás eszközt, amíg használható, kínos.

4. Google Keep

A Google Keepben a hagyományos noteszkészítésen kívül lehetőség van emlékeztetők beállítására is, ami a Google Calendarnak a kezdetektől fogva alapfunkciója, azaz ha valaki szeretné értelmetlenül megbonyolítani az életét, akkor egy Google-fiókon belül két különböző helyre is mentheti az emlékeztetőket, mivel a kettő egymástól teljesen független, amire ügyelni kell, ha valaki az emlékeztetőit egy helyen, rendben szeretné tárolni.
A Google Keep minden Google-től várható feltételt teljesít, áttekinthető a felület, de felhasználói élmény gyakorlatilag nincs, ezen kívül nagy eséllyel jut a Google Reader sorsára, amit sokan is használtak, sokan is szerettek, viszont a Google nem tudott a megtérüléshez szükséges információt kinyerni a felhasználói bázisából. Teljesen általános, hogy a Google kivezet minden olyan szolgáltatást, amin keresztül nem sajtolható ki elég információ a userbase-ből.


megszunt_google_szolgaltatasok.png

5. Quip

Az alapvetően csoportmunkát támogató suite részét képző lightweight megoldás integrálható bármivel, minden ritkán használt, értelmetlen funkciót gondosan kigyomláltak belőle, így kimondottan régi eszközökön is nagyon gyors kliensprogrammal és webes felületen egyaránt. Fontos eltérés, hogy a többivel szemben a Quip még nem támogatja a kétlépcsős hitelesítést.

quip_software_suite.png
6. Zoho Notebook

A Zoho-csomag részeként ingyenesen elérhető szolgáltatás a Zoho Writer egyszerűsített változatának tűnik, mindennel, amire szükség van egy jegyzetelőappban, a Quip megoldásához hasonlóan alapértelmezés szerint egy privát és egy osztható mappát tartalmaz, amelyikbe lehet rendszerezni a feljegyzéseket.

zoho_notebook.jpg

7. Simplenote

Amellett, hogy a Simplenote erőssége éppen az egyszerűsége, nem fordulhat elő olyan, mint nagyon sok más megoldásnál, azaz, hogy egy átgondolatlan megosztással repül ki a dokumentum egyszerűen URL-lel elérhető formában a netre: ehhez a címkék közé fel kell venni annak a felhasználónak az email-címét, akivel megosztanánk a feljegyzést. A kétlépcsős hitelesítés még ugyancsak hiányzik.
simplenote.png

8. Dropbox Paper

Viszonylag új versenyző a terepen, a Dropbox által felvásárolt Hackpad továbbfejlesztéseként azoknak lehet kényelmes választás, akik kimondottan a dropboxos környezethez szoktak hozzá. Félúton van az egyszerű noteszalkalmazások és wordprocessorok közt.
dropbox_paper.jpg
 
9. Nimbus Note

Az OSX-et leszámítva az összes nagyobb platformra elérhető, sok másiktól eltérően van egy hatalmas előnye: egy-egy megosztásnál lehetőségünk van úgy dönteni, hogy nem bízunk önmagában a security through obscurity-ben, aminek az alapgondolata, hogy a megosztás URL-jében lévő link kellően barokkos ahhoz, hogy ne lehessen kitalálni véletlenül. A megosztásoknál külön-külön jelszót lehet beállítani.
nimbus_note.png

10. Laverna

Meglehetősen kilóg a sorból, az alkalmazás nem is ad tárhelyet, ehelyett beállíthatjuk egy egyszerű API-kulccsal, hogy az alkalmazás a például a Dropbox-fiókunk tárterületét használja. Az alkalmazásban lehetőség van megadni a titkosításhoz szükséges kulcs mérete mellett egyedi salt-et is.
laverna_notes.png
Érdemes szem előtt tartani, hogy ezek mindegyike vagy majdnem mindegyike mindent tud, amit egy általános célú jegyzetelő szolgáltatásnak tudnia kell, a motorháztető alá benézve pedig még annál is többet, míg a komplexebb feladatokra ott vannak a wordprocessorok, amiről ugyancsak szó lesz. A papírlapú eszközök jórésze ezekkel már lecserélhető, függetlenül egy-egy szervezet méretétől és profiljától, azoknak a productivity tooloknak is kiemelt szerepük van, amik látszólag nagyon egyszerű feladatot látnak el. Nem is akármilyen szerepük: hasonlóan nagyon sok más eszközhöz, egész egyszerűen lemaradnak azok a szervezetek, akik nem térnek át minél korábban a célnak megfelelő csoportmunkát támogató eszközök használatára.

Hogy az elévült eszközökhöz, lényegében megszokásokhoz való ragaszkodás miért jár sokszor észrevétlen, rendkívüli idő- és pénzveszteséghez, többféleképp is megközelíthető, amiről a posztsorozatban elméletibb szempontból is visszatérek.

képek forrása: Wikipedia, Evernote blog, Wordstream, Thenextweb

3 komment

A nuget.org két órán keresztül nem volt elérhető. Az ok: lejárt tanusítvány

2018. március 26. 08:35 - Plesz Gábor

Egyelőre csak egy rövid közlemény jelent meg erről, de a helyzet nem teljesen ismeretlen számomra sem. Évente/kétévente lejár a tanusítvány, és ezt szinte mindig elfelejti mindenki, aztán van a kapkodás. Az egyik jó megoldást már írták is a kommentben a közleményre:)

Incident report - NuGet.org downtime on March 22, 2018

Volt már ilyen veletek?

1 komment

C# forráskód: Szerver oldali Gameboy emulátor .NET Core és Angular megvalósítással

2018. március 07. 12:03 - Plesz Gábor

Valaki megírta a 80-as évek Nintendo sikerét, a GameBoy videójátékot szerver oldalon C# nyelven, Angular felülettel. Ehhez készített egy Z80 emulátort komplett teszt lefedettséggel, és ezt khm. egészen szépen dokumentálta is. Hanselman szerint egészen kíváló forráskód, ínyenceknek kötelező!

Hanselman: A multi-player server-side GameBoy Emulator written in .NET Core and Angular

Szólj hozzá!

Hogy kerülhetjük el a "szoftverpusztulást"? 12Factor app: 12. Adminisztratív folyamatok

2018. március 02. 05:00 - Plesz Gábor

Előző fejezet: 11. Naplók

Az adminisztrációs és felügyeleti feladatokat futtassuk egyszer futó folyamatokként

A folyamat formája pedig legyen olyan folyamatok együttese, amit az alkalmazás rendszeres üzleti folyamatai (például webes kérések kiszolgálására) is használnak. Ezen kívül a fejlesztők gyakran egyszeri adminisztrációs vagy karbantartási feladatokat is szeretnének végrehajtani, mint például:

  • Adatbázis migrációk végrehajtása (pl.: manage.py migrate a Django-nál, rake d:migrate a Rails használatakor vagy migrate.exe a .NET Entity Frameworkben)
  • Konzol használata (vagy másnéven REPL shell) tetszőleges kód futtatásához vagy akár az alkalmazás adatmodelljének használatához az éles adatbázis vizsgálata közben. A legtöbb nyelv biztosít REPL eszközt az értelmező alkalmazás parancssori paraméterek nélküli futtatásával (mint a python vagy a perl), egyes esetekben pedig erre külön parancs van (mint az irb a Ruby-hoz, rails console a Rails-hoz).
  • Az egyszer használatos scripteket az alkalmazás kódtárában kell tárolni (egy php példa: scripts/fix_bad_records.php).

Az egyszeri adminisztrációs folyamatokat ugyanolyan környezetben kell futtatni, mint az alkalmazás rendszeres, hosszan futó folyamatait. Ugyanazt a kódbázist és konfigurációt használó telepítés mellett futtatva, mint amit telepítés egyéb folyamatai használnak. Az adminisztrációs kódokat az alkalmazással együtt kell szállítani a szinkronizációs problémák elkerülése érdekében.

Ugyanazt az elkülönítési megoldást kell használni minden folyamattípusnál. Például, ha a Ruby webes folyamata a bundle exec thin start parancsot használja, akkor az adatbázis migrációnak bundle exec rake db:migrate-et kell használnia. Hasonlóan, a Virtualenv-et használó Python programnak a saját bin/python köyvtárát kall használnia a Tornado webkiszolgáló indításához ugyanúgy ahogy minden manage.py felügyeleti folyamathoz.

A tizenkét tényezős fejlesztés határozottan támogatja azokat a nyelveket, amik alapból kínálnak REPL környezetet és megkönnyítik az egyszeri adminisztrációs scriptek futtatását. A fejlesztők a saját gépükön az egyszeri admin scripteket egyből az alkalmazás munkakönyvtárából tudják parancssorban futtatni. Éles telepítés esetén a fejlesztők ilyen folyamatok futtatásához ssh-t vagy más, a telepítés futtatási környezete által biztosított távoli parancsvégrehajtási megoldást használhatnak.
The Twelve-Factor App: XII. Admin processes
Szólj hozzá!