NetAcademia

A legjobbakat tanítjuk!

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á!

A programozók jogairól - egy lehetséges alkotmánykiegészítés :)

2018. február 27. 06:00 - Plesz Gábor

Hű de régi ez a cikk, mégis milyen jó :)

A USA alkotmány kiegészítéseinek mintájára a szerző összeírta, hogy milyen jogokat védhetne akár törvény is egy programozók által elképzelt ideális világban (a cikk 2006-ban íródott).

Röviden:

  1. Minden programozónak biztosítani kell két monitort.
  2. Minden programozónak gyors számítógép jár.
  3. Minden programozó saját egeret és billentyűzetet választhat.
  4. Minden programozónak kényelmes szék jár .
  5. Minden programozónak biztosítani kell gyors Internet elérést.
  6. Minden programozónak elidegeníthetetlen joga a csendes munkakörnyezet.

Részletek a linken:

Jeff Atwood: The Programmer's Bill of Rights

1 komment
Címkék: JeffAtwood

Fejlesztőknek: Vajon érdemes Entity Framework mellett Repository mintában gondolkodni?

2018. február 23. 08:53 - Plesz Gábor

A kolléga .NET Core ügyekben kotangens, érdemes átnézni a blogját, igényes cikkeket ír.

Repository minta kiváló eszköz arra, hogy az adatok perzisztenciájáért felelős komponens, és az adatokat felhasználó komponensek erős csatolását megszüntessük (indirekció segítségével). Rengeteg példa megtalálható a neten arról, hogyan érdemes kódolni repository (és Unit of Work) mintát mindenféle nyelven, Entity Framework-öt használva vagy anélkül. Ez a cikk egy racionális áttekintés arról, hogy vajon érdemes-e repository mintát használni Entity Framework környezetben?

Ki mit gondol erről?

Jon P Smith: Is the repository pattern useful with Entity Framework Core?

Szólj hozzá!

Fejlesztőknek: hogyan tegyük érthetőbbé a feltételvizsgálatot a forráskódban? (C++)

2018. február 21. 09:26 - Plesz Gábor

Most találkoztam ezzel a kollégával először, de egyből megtetszett a blogja. Egyszerű, érthető, azonnal felhasználható kódolási tanácsokat ad C++ példákkal, de minden fejlesztő számára érthető módon.

Érdemes végigböngészni a blogot, szerintem aranybánya.

Jonathan Boccara: How to Make If Statements More Understandable

 

Szólj hozzá!

Hogy kerülhetjük el a "szoftverpusztulást"? 12Factor app: 11. Naplók

2018. február 19. 17:48 - Plesz Gábor

Előző fejezet: 10. Egyensúly a fejlesztés és az üzemeltetés között

Kezeljük a naplókat esemény-folyamatként

A naplók a futó alkalmazás működésébe nyújtanak betekintést. Szerver alapú környezetben gyakran a lemezen egy állományba írják őket ("naplóállomány"); de ez csak egy kimeneti formátum.

A naplók valamennyi futó folyamat és háttérszolgáltatás kimeneti adataiból összegyűjtött és idő szerint rendezett adatfolyama. A naplók nyers állapota tipikusan szöveges formátum ahol minden esemény külön sorban szerepel (akkor is, ha a kivételekből származó veremtartalom több sorba is kerülhet). A naplóknak nincs meghatározott elejük vagy végük hanem folyamatosan keletkeznek egészen addig, amíg az alkalmazás üzemel.
A tizenkét tényezős alkalmazás saját maga sosem foglalkozik a saját kimeneti adatfolyamának irányításával vagy tárolásával. Nem szabad naplófájlokat írnia vagy kezelnie. Helyette minden futó folyamat a saját eseményeit gyorsítótár nélkül kiírja a sztenderd kimenetre (stdout). A fejlesztés alatt a fejlesztő a saját képernyője előtt ülve fogja nézni, hogy megfigyelje az alkalmazás viselkedését.

A tesztelési vagy az üzemeltetési telepítéseknél minden folyamat adatfolyamát a végrehajtási környezet rögzít, összevonva az alkalmazás összes többi adatfolyamával, megtekintésre és hosszútávú archiválásra egy vagy több végcél felé irányítva. Ezek az archívumok nem láthatók és konfigurálhatók az alkalmazásból, helyette teljes egészében a futtatókörnyezet kezeli őket. Ehhez nyílt forráskódú napló forgalom írányító eszközök állnak rendelkezésre (mint a Logplex és a Fluentd).

Az alkalmazás eseményeinek adatfolyamát irányíthatjuk állományba, vagy valós időben figyelhetjük terminálablakban. A legfontosabb, hogy az adatfolyamot elküldhetjük egy naplóindexelő és elemző rendszerbe, mint a Splunk, vagy egy általános célú adattárház eszközbe, mint a Hadoop/Hive. Ezek a rendszerek elegendő teljesítményt és rugalmasságot biztosítanak az alkalmazások időbeli viselkedésének megismeréséhez, ideértve:

  • Meghatározott múltbeli események keresése.
  • A trendek tágabb nézőpontból történő ábrázolása (mint a percenkénti kérések száma).
  • Aktív riasztás a felhasználó által létrehozott figyelésnek megfelelően (például egy riasztás jön létre, ha a percenkénti hibák száma meghalad egy bizonyos küszöbértéket).

The Twelve-Factor App: XI. Logs

Szólj hozzá!

Hogy kerülhetjük el a "szoftverpusztulást"? 12Factor app: 10. Egyensúly a fejlesztés és az üzemeltetés között

2018. február 12. 09:44 - Plesz Gábor

Előző fejezet: 9. Eldobhatóság

A fejlesztési és az üzemeltetési folyamatok legyenek annyira hasonlóak amennyire csak ez lehetséges.

Történeti okokból jelentős különbségek vannak a fejlesztés (a fejlesztő az alkalmazás helyi telepítését élőben módosítja) és az üzemeltetés (az alkalmazás végfelhasználók által elérhető, éppen futó telepítése) között. Ezek a különbségek és az ezekből adódó problémák három területen jelentkeznek:
  • Az idő különbség: a fejlesztő a kódon dolgozhat napokig, hetekig vagy akár hónapokig, mire a munkája az üzemeltetett alkalmazásba kerülne.
  • A személyi különbség: A fejlesztő írja a kódot, az üzemeltető mérnök telepíti azt.
  • Az eszköz különbség: a fejlesztő dolgozhat olyan csomaggal, amiben Nginx, SQLite és OS X van, az üzemeltetés viszont Apache, MySQL és Linux környezetre telepíti az alkalmazást.
A tizenkét tényezős alkalmazást eleve folyamatos telepítéshez tervezzük, hogy ez a különbség a fejlesztés és az üzemeltetés között kicsi legyen. Nézzük a három különbséget egyenként:
  • Az időbeli különséget tegyük kicsivé: a fejlesztő írhatja a kódot, és az órák vagy akár percek múlva az üzemeltetésbe kerülhet.
  • A személyi különbséget tegyük kicsivé: a kódot író fejlesztőt szorosan bevonjuk a a telepítésbe így közelről figyeli az üzemeltetésben az alkalmazás viselkedését.
  • Az eszközökben megjelenő különbséget tegyük kicsivé: legyen a fejlesztési és az üzemeltetési környezet olyan hasonló, amennyire csak lehet.
Összegezve ebben a táblázatban:
Hagyományos alkalmazás Tizenkét tényezős alkalmazás
Telepítések közötti idő Hetek Órák
Kód létrehozó kontra telepítő Különböző emberek Ugyanazok az emberek
Fejlesztési kontra üzemeltetés Szétágazó, különböző Amennyire lehetséges hasonló
 
A háttérszolgáltatások, mint az alkalmazás adatbázisa, az üzenetsor vagy a gyorsítótár olyan terület, ahol a fejlesztés és az üzemeltetés egyensúlya fontos. Sok nyelv kínál könyvtárakat, amik egyszerűsítik a hozzáférést a háttérszolgáltatáshoz, ideértve adaptereket a különböző típusú szolgáltatásokhoz. Néhány példa táblázatban:
Típus Nyelv Könyvtár Adapter
Adatbázis Ruby/Rails ActiveRecord MySQL, PostgreSQL, SQLite
Üzenetsor Python/Django Celery RabbitMQ, Beanstalkd, Redis
Gyorsítótár Ruby/Rails ActiveSupport::Cache Memory, filesystem, Memcached

A fejlesztők néha nagyon vonzónak találják, ha fejlesztés közben pehelysúlyú háttérszolgáltatást használhatnak a saját fejlesztési környezetükben, míg erős háttérszolgáltatások kerülnek az üzemeltetési környezetbe. 
Például fejlesztéshez SQLite-ot üzemeltetéshez viszont PostgreSQL-t használni; vagy helyben a folyamat memóriáját, üzemeltetéskor pedig Memcached-et használni gyorsítótárazáshoz.

A tizenkét tényezős fejlesztő ellenál annak a kísértésnek, hogy más háttérszolgáltatást használjon a fejlesztési és az üzemeltetési környezetben még akkor is, ha az adapterek elméletileg bármilyen háttérszolgáltatások közötti különbséget eltüntetnek. A háttérszolgáltatások közötti különbségek azt jelenti, hogy apró inkompatibilitási problémák merülhetnek fel azt eredményezve, hogy a kód, ami működött és a teszteken megfelelően teljesített fejlesztési és tesztkörnyezetben, üzemeltetés közben hibára fut. A hibáknak ez a típusa súrlódást hoz létre ami a folyamatos telepítést akadályozza. Ennek a surlódásnak a negatív hatása a folyamatos telepítésre és az alkalmazás életciklusára összegzett kültsége rendkívül magas.

A pehelysúlyú háttérszolgáltatások ma már kevésbé vonzóak, mint korábban voltak. A modern háttérszolgáltatásokat, mint a Memcached, a PostgreSQL és a RabbitMQ a modern csomagkezelési rendszereknek köszönhetően -mint a Homebrew és az apt-get, (vagy a Windows világban a nuget és chocolatey) egyáltalán nem körülményes telepíteni és futtatni. Alternatív megoldásként a deklaratív telepítő eszközök, mint a Chef és a Puppet, kombinálva a vékony virtuális rendszerekkel, mint a Docker és a Vagrant lehetővé teszi a fejlesztők számára, hogy az üzemeltetési környezethez nagyon hasonló fejlesztési környezetben dolgozhassanak. Ezen rendszerek telepítésének és használatának a költsége alacsony - összehasonlítva a fejlesztési és üzemeltetési egyensúllyal valamint a folyamatos telepítés előnyeivel.

A háttérszolgáltatások eléréséhez adaptereket használni továbbra is hasznos, mivel az újabb háttérszolgáltatásokra való áttéréet relatív fájdalommentessé teszik. De az alkalmazás valamennyi telepítésének (fejlesztési környezet, tesztelés és üzemeltetés) azonos típusú és verziójú háttérszolgáltatásokat kell használnia.

The Twelve-Factor App: X. Dev/prod parity

Szólj hozzá!