Power Bank - Hogyan kerüljük el az átveréseket vésztöltők, külső aksik vásárlásánál?

Körülbelül négy hónapja figyelek egy Milyen külső akkumulátort mobileszközökhöz? nevű fórum, és utánanyomoztam egy-két dolognak a témában. Ezért gondoltam, hogy leírom az ezzel kapcsolatos konklúziókat, hátha valakinek segít elkerülni a csalókat későbbiekben. Tudni illik rengeteg hamis vésztöltő van az ebay-en. 2015.10.28-i árfolyamokat használtam, a pénzváltást a google-el végeztem.

Representational State Transfer - értesítések küldése a kliens felé

Összefutottam mostanában több arra vonatkozó kérdéssel REST-el kapcsolatban, hogy hogyan leheta klienst értesíteni arról, ha valami őt érintő esemény történik a szerveren. Az egyik ilyen kérdés volt, hogy SSE-t szabad e használni egy REST service-ben, a másik ilyen kérdés, meg hogy mi a legjobb megoldás arra az esetre, ha hosszú feldolgozási idejű kérések vannak REST-nél. Megpróbálom összefoglalni a véleményemet a témában.

Representational State Transfer - a service-ek feletti tranzakciókat ha lehet kerüljük

Találkoztam egy érdekes kérdéssel stackoverflow-on azzal kapcsolatban, hogy hogyan lehet tranzakciókat használni több REST service összehangolására. A válasz elég egyértelmű, sehogy. Azt is leírom, hogy miért, mert nekem is utana kellett kicsit olvasni meg gondolni, hogy kézenfekvő legyen.

Hálózatos alapok - port, socket, connection különbség

Eddig nem nagyon néztem utána ezeknek a hálózatos alap dolgoknak, de most, hogy fejlesztem az üzenet küldős alkalmazásomat aszinkron javascript-hez kénytelen vagyok utánajárni a szakszavaknak és a meglévő üzenetküldős technológiáknak, hogy ne legyen teljesen légbőlkapott a dolog. Ami számomra meglepetés volt, hogy mennyi embernek okoz gondot különbséget tenni eközött a 3 fogalom között: port, socket, connection. (Nincs értelme lefordítani a szavakat magyarra, mert az csak még nagyobb zavart okozna a fejekben.)

A URI és HTTP szabványok érdekességei - a vary header

A Representational State Transfer - interface constraints és ajánlott szabványok bejegyzésben elég részletesen kitárgyaltam az URI standard egy érdekességét, hogy hogyan lehet valós életbeli dolgokat azonosítani egy-egy fragment identifier-es IRI használatával. Ebben a bejegyzés sorozatban szeretném egy kicsit jobban kibontani a URI és HTTP szabványokat, mert nagyon sokan, akik webre fejlesztenek, nem ismerik kellőképp ezeket a szabványokat. Ami egyrészt szomorú, másrészt meg én is közéjük sorolom magam, és megnőtt bennem az igény a változásra.

A mostani bejegyzés a vary header-ről fog szólni, illetve arról, hogy hogyan lehet felhasználni felhasználóra, böngésző típusra, MIME típusra, nyelvre és tömörítési formára specifikus tartalmak kesselésére. Természetesen a gyakorlati felhasználása még ennél is jóval szélesebb körű ennek a header-nek.

Edzéselmélet - saját edzésterv - blokk helyett inkább kevert

Június (2015) eleje óta, amikor összeraktam a blokk periodizációs edzéstervemet, sok víz lefolyt a Dunán, úgyhogy gondoltam írok egy kis update-et. Elkezdtem végrehajtani az edzéstervet, annak rendje és módja szerint. Körülbelül 1 hónapig bírtam, utána lesérültem. Azóta is ezzel a sérüléssel küszködök. Kb. arról van szó, hogy gyenge a vádlim alsó része, az ún. soleus, és ezért nem védi eléggé az Achilles ínt, illetve a hozzá kapcsolódó nyák tömlőt a sérüléstől. Úgy látszik nekem is ez az Achilles sarkam. :D A cipőmmel is baj van, túl passzentos, vagy nem olyan a sarok része, mint ami nekem való. Mivel nem vagyok nagy cipő szakértő, ezért nem tudom eldönteni.

node.js - streams & pipes

A fenti fogalmakat hajlamosak a node.js dokumentációban és úgy általában a cikkekben is elbonyolítani, amit úgy gondolom már nem hagyhatok szó nélkül, mint ügyeletes megmondóember. ;-)

A nagy disztró teszt - követelmények

Az előbbiekben már említettem, hogy szubjektív lesz a mércéje a disztrók használhatóságának. Ez persze nem azt jelenti, hogy egy-egy rendszer bemutatása abban ki fog merülni, hogy tetszett vagy nem tetszett. Szeretnék legalább minimális követelményeket meghatározni egy-egy rendszerre vonatkozóan. Ezek idő közben elképzelhető, hogy változni fognak, ha belefutok egy-egy váratlan hibába, így folyamatosan frissítem majd a listámat. A listán megadom egy-egy követelménynek az általam adott angol nevét is, és előfordulhat, hogy a későbbiekben ez alapján hivatkozom majd rá. Ha az angol név vastag betűs, akkor szükséges kritériumról van szó, ami ha nem teljesül, akkor először megpróbálok megoldást találni, ha viszont ez nem teljesül, akkor sokszor nem tesztelem tovább a disztrót. A normál betűs kódnév azt jelenti, hogy fapados a disztró az adott feature nélkül, de azért el lehet boldogulni vele. A dőlt betűs kódnév esetében pedig csak extráról van szó, ami jó ha van, de nem szükséges a mindennapi használathoz.

A nagy disztró teszt - hardver környezet

Meguntam a Windows-t, több okból is. Az egyik, hogy nálam 100GB már nem elég egy Windows 7-nek, konkrétan 97GB-nál tart. Ebből körülbelül 20GB ami saját adat és program, a többi szemét, amivel telehordta a gépet a 6 év alatt, mióta fent van. Úgy gondoltam, hogy lassan ideje váltani. Első jelölt nálam a Windows 8.1 volt, mert a tabletemen az van fent, és nagyjából ugyanazt tudja, mint a Windows 7, csak hatékonyabban, és nem mellesleg 10GB-on elfér. Időközben kijött a Windows 10 is, aminél a review-ok olvasgatása elég mellbevágó élmény volt. Mint kiderült a Windows egy ideje már kémkedik a felhasználói után, és ezt a feature-t a Windows 8.1-be és a Windows 7-be is utólag beépítette a frissítésekkel. Vannak módszerek, amikkel lehet korlátozni a dolgot, pl vezérlőpult error reporting és security beállításoknál, illetve service-ek leállításánál, update package-ek törlésénél, és így tovább, de azt mondják virtuális gépen még így is tisztán látszik a Windows adatforgalma, amit a háttérben bonyolít. Ezt alátámasztják a saját megfigyeléseim is, kaptam kék halált Windows 8.1-nél kikapcsolt error reporting-al, amiben azt írták, hogy adatokat gyűjtenek a rendszerről, amit továbbítanak a Microsoft-nak. Nem volt apelláta, választási lehetőség, sőt még a power gomb nyomva tartása sem működött. Ez szerintem elfogadhatatlan, ezért gondoltam arra, hogy megnézek néhány Linux disztrót, hogy vajon reális alternatívái e a Windows rendszereknek. Aki nem ismerné a szót, a distribution rövidítéséről van szó, szóval ezek Linux változatok. Úgy kell elképzelni, mintha mondjuk a Windows 7-ből és a Vista-ból csináltak volna 10 félét. Mind egy kicsit eltérő, eltérő asztallal, valamennyire eltérő kernellel, és így tovább, de alapjaikban azért elég hasonlóak egymáshoz. A Linux is valami ilyesmi, csak több ezer disztró létezik egymáshoz képest kisebb nagyobb eltérésekkel.

A legolcsóbb szerver - az adathordozó

A legolcsóbb szerver összerakásánál szó volt már a dobozról, ami nagy valószínűséggel egy PogoPlug v4, vagy valami hasonló olcsóbb eszköz lesz. Ez támogat SATA2-t, USB3-at, SD kártyát, szóval minden adott ahhoz, hogy valami jó sok tárolóhellyel rendelkező eszközt hozzácsatoljunk. Nézzük hát sorra, hogy mik jöhetnek szóba.

A legolcsóbb szerver - a doboz

Szeretnék egy szervert itthonra központi tárolónak, amin a saját itthoni projektek futnak, és amivel a gépek között meg tudnék osztani fájlokat anélkül, hogy pendrive-al kellene ide-oda futkároznom, vagy hálózaton keresztül kellene mappákat megosztanom. A lehető legolcsóbb még működő megoldásra gondoltam, ami átlépi az USB2 sebességét, szóval tudnia kell vagy SATA2-t vagy USB3-t és persze gigabites adatátvitelt. Sebességben ami megfelel nekem az a 100MB/s feletti olvasás, és a 60MB/s körüli írás. A határa a gigabites kapcsolatnak 120MB/s, szóval ezek beleférnek. A wifi nem volt szempont, mert úgyis a modem mellé kötöm be a szünetmentesre. A RAID sem volt szempont, mert ami lényeges, arról úgyis külön csinálok backup-ot.

Edzéselmélet - saját edzésterv

Lassan egy év teljesen rendszertelen edzés után úgy gondoltam ideje valami struktúrát vinni a dologba, mert nem vezet sehova. Magukkal az edzésekkel nincs gond, egyáltalán nem nehéz egy kemény edzést összerakni. Ami már bonyolultabb, az a hosszú távú edzésterv összerakása.

Párhuzamosítás PHP-ben

Nem egy gyakori probléma PHP-ben, de azért előfordulhat, hogy bizonyos dolgok párhuzamosítására van szükség. Nézzük mik lehetnek ezek az esetek:
  1. CRON-ból vagy command line-ból szeretnénk több, egymástól független feladatot futtatni úgy, hogy ha az egyik feladat hibával elszáll, akkor az ne hasson ki a többire
  2. RSS feed-eket szeretnénk lerántani cURL-el tömeges feldolgozásra, esetleg azonnali megjelenítésre
  3. képeket szeretnénk átméretezni, jó sokat
  4. szeretnénk szétválasztani bizonyos szempontból független, bizonyos szempontból összetartozó kódokat, pl fájlrendszer és adatbázis módosító utasításokat, hogy könnyebben érthető kódot kapjunk
  5. szeretnénk leválasztani egy lassú folyamatot, hogy amíg dolgozik, addigis tudjuk folytatni a munkánkat a többi adattal, pl miközben a feltöltött profil képet méretezi át a rendszer, addig betegyük a nevet és az email címet a regisztrált felhasználóhoz
és még folytathatnám tovább, hosszú a sor. Az esetek többségében sebességi megfontolásokról van szó, a kisebb részükben pedig kód olvashatóság és karbantarthatóság a fő szempont.

(Ezt a cikket importáltam, eredetileg 2014-ben írtam egy programozással foglalkozó oldalra.)

Alapvető biztonság – Code Injection

Az alapvető biztonság rovatban néhány alapvető webes biztonsági kérdést szeretnék ismertetni abban a reményben, hogy a jövőben a magyar webalkalmazások valamivel biztonságosabbak lesznek. A mai cikkben a code injection-ről lesz szó.

(Ezt a cikket importáltam, eredetileg 2014-ben írtam egy programozással foglalkozó oldalra.)

Tudásgráf projekt

Szeretnék egy tudásgráfot összehozni immunológiával kapcsolatban. Eredetileg a projekt úgy indult, hogy szerettem volna átlátni az interleukin hálózatot, hogy hogyan működik autoimmun betegségeknél, de jelen pillanatban van körülbelül 150 interleukin, és mindegyikhez legalább ezer cikk különböző témákban. Nagyon esélytelen, hogy ebben az évtizedben végeznék az olvasással, nem is beszélve arról, hogy közben még sokszor ennyi cikket kitermelne a tudós társadalom közben. Arra gondoltam, hogy jó lenne összegezni a cikkekben található információkat egy gráfba, amiből nagyjából mindenki le tudja követni, hogy milyen szabályozó mechanizmusokkal működik az immunrendszer, és az ebbe való beavatkozás milyen következményekkel jár. Ideális esetben a kísérletek alapján lehetne egy számítógépes modelt csinálni az immunrendszer működéséről, de véleményem szerint még nagyon messze vagyunk attól, hogy ez a model akár csak korreláljon a valósággal. Mindenesetre próbálkozások vannak, az enyém is egy lesz a sok közül.

Human physiology - A vörösvértestek evolúciós szerepe

Volt pár érdekes kérdés biology.stackexchange-en, amit megválaszoltam. Gondoltam írok ide egy-egy összefoglalót mindegyikről, mert szerintem érdekesek. Az egyik ilyen volt, hogy mi a szerepük a vörösvértesteknek (RBC: red blood cell), nem e lenne elég pusztán a hemoglobint (HGB) utaztatni a vérben? Az angol nyelvű válasz itt található a referenciákkal együtt.

Aki nem lenne tisztában a témával az RBC-k termelik a HGB-t (ami egy fehérje) az életük egy korai szakaszában. Jó sok van bennük, egész lerakat, ettől olyan vörösek, mert a HGB vasat tartalmaz, tehát szép magyar szóval metalloprotein. A HGB képes megkötni az oxigént (O2) és a széndioxidot (CO2), így van lehetőség ezeknek a gázoknak a vérbe történő beoldására és szállítására.
Azt fontos tudni ezzel kapcsolatban, hogy a gázok vízben való oldása nyomás és hőmérséklet függő. Légköri nyomáson, és 37°C-on nem igazán tud sok gázt beoldani a víz vagy a vér (nagy része víz annak is). Nagyobb nyomáson már más a helyzet, ezért van például a keszon betegség, amikor hirtelen jönnek fel a búvárok és nitrogén (N2) buborékok keletkeznek a vérükben. Ugyanez a helyzet, ha kinyitjuk a bubis vizet. Hirtelen lecsökken a nyomás, és kiválnak a gázok. Ha meleg a víz, akkor meg egyenesen beterít minket a bubis víz, mert magasabb hőmérsékleten kevesebb gázt tud beoldani a víz.
A vérrel az a helyzet, hogy HGB nélkül nem maradnánk életben a légköri nyomáson, mert annyira kevés O2-t és CO2-t tud beoldani. Az O2 nyilván a mitokondriumokba kell a terminális oxidációhoz, ha nincs belőle elég, akkor maximum tejsavas erjesztésből van energia (ha képes rá az adott sejttípus), és a legtöbb sejt egy bizonyos idő után elhal. Az agysejtek hamarabb kezdenek elhalni (5-10 percet meg lehet úszni agykárosodás nélkül), a szívizomsejtek jóval többet bírnak (kb 2 óráig kórházba kell kerülni az illetőnek szívroham esetén). Szóval a HGB normál légköri nyomáson nélkülözhetetlen.
A vér keringetése ugyanígy nélkülözhetetlen. A rovaroknak nincs hasonló keringésük, és ezért nem tudnak a jelenlegi méretüknél nagyobbra nőni. A diffúzió nem tud elég oxigént szállítani. Nagyobb nyomáson vagy magasabb O2 szintnél a rovarok is sokkal nagyobbak lennének.

Representational State Transfer - saját REST service-nél felhasználó azonosítás OpenID-vel? Egyáltalán lehetséges ez?

Sok weboldal használ OpenID-t ahhoz, hogy regisztrálja és beléptesse a felhasználóit. Egészen elszállt esetekben akár egy tucat identity provider is fel van sorolva, mint lehetőség, pl Google, Microsoft, Yahoo, PayPal, Facebook, Twitter, stb... A Facebook és a Twitter tudtommal nem OpenID-t használnak, de nekik is van REST API-juk, amin keresztül identitást el lehet kérni. Van még kismillió ilyen cég. Lényeg a lényeg, rajtuk keresztül tudjuk elkérni valakinek az identitását OAuth2-t használva. Ezt most nem részletezem, hogy hogyan zajlik, elég annyi, hogy a felhasználó összekattintja a böngészőben, hogy engedi nekünk, hogy hozzáférjünk az email címéhez, és pár HTTP redirect után a 3rd party REST kliensünk megkapja az email címet. Ezek után a legtöbb oldal beteszi szerver oldali session-be ezt az info-t, esetleg a hozzá tartozó user id-t, és pont.

Representational State Transfer - interface constraints és ajánlott szabványok

Az előző bejegyzésben már említettem, hogy van négy interface constraint:
  1. identification of resources
  2. manipulation of resources through representations
  3. self-descriptive messages
  4. hypermedia as the engine of application state
Ezeket fussuk gyorsan át. Nyilván protokollnak a HTTP-t használjuk, mert ez fekszik legjobban a REST-nek.

Representational State Transfer - alapvető ismeretek

Sokszor olvasom neten, hogy valaki REST APIt vagy RESTful webservice-t csinál, mert ez az újabb hype már egy pár éve a SOAP után. Nálunk ez itthon annyira még nem gyűrűzött be, mert kicsi a magyar piac, és trendek terén néhány évvel el van maradva a nyugattól.

Én még 2012-ben kezdtem el ismerkedni a REST-el. Beleestem abba a hibába, hogy online tutorial-okból próbáltam megtanulni, illetve stackoverflow-os kérdésekre adott válaszokból. Kellett pár hónap, mire rájöttem, hogy ez nem járható út, mert ezeknek az írásoknak szinte 100%-a teljesen használhatatlan, a készítőik pedig valószínűleg egyformán képzetlenek ezen a téren és vakok közt a félszemű a király alapon egymást oktatják. Talán a legfontosabb pillanat volt ezzel kapcsolatban, amikor valaki ajánlotta, hogy olvassam el a Fielding disszertációt - amit Roy Thomas Fielding írt még 2000-ben - mert súlyos tévedéseim vannak REST-el kapcsolatban. Persze nem hittem neki, hiszen mindent tudtam már a tutorial-okból, dehát azért nekikezdtem, aztán egyik döbbenetből estem a másikba.

Clean Code - Miért fontos a beszélő kód, és miért rossz a sok comment?

Az előzőekben tehát lejött, hogy a kódolásnál igazából absztrakciós szintek és felelősségi körök szerint daraboljuk fel a kódot kis egységekre, osztályokra, metódusokra, és így tovább. Ez egy része a dolognak. A másik része a clean code-nak, hogy milyen osztály, metódus és változóneveket használunk.

Ez elsőre nem tűnik valami fontosnak. Annak idején én is úgy kezdtem a programozást, hogy az abc összes betűjét felhasználtam. Sokan megkérdezték, hogy ez már az obfuszkált kód és hogy hol az eredeti, meg hogy hogyan vagyok képes ezt elolvasni? Így utólag elég vicces visszagondolni rá.

Cean Code - SRP (single responsibility principle), tell don't ask, god object

Az absztrakciós szinteknél már kitárgyaltuk, hogy a DRY arra képes, hogy az ismétlődő kódot beteszi alacsony absztrakciós szintre, annak a hívását meg magas absztrakciós szintre emeli. Így általánosít. Ennek az az eredménye, hogy szép rétegek alakulnak ki, minden rétegben egyre alacsonyabb absztrakciós szintű kóddal. A felhasználótól jövő adat áramlása ezeken a rétegeken keresztül történik magas absztrakciós szintről az alacsony felé, és természetesen visszafelé is, amikor a program válaszol.

Az SRP ennél annyival tud többet csinálni, hogy horizontálisan is széttagolja a kódot. Ezt úgy éri el, hogy kimondja, hogy egy osztálynak csak egyetlen feladatköre lehet. Így ha eddig mondjuk egyetlen nagy osztály - ún. god object - látott el egy csomó feladatot, akkor ezentúl több kicsi osztály fogja megcsinálni ugyanazt. Természetesen ez is eredményezhet a horizontális mellett vertikális tagolást, ha két ilyen kicsi osztály feladatát össze kell hangolni a kódban egy magasabb szintű osztályból. Az SRP megszegésének így több változata lehetséges. Ilyen például a már említett god object, aminél a felelősségi köröket mosunk össze (megsértjük a horizontális és esetleg a vertikális tagolást is). Szintén egy változat ha egymás alatti absztrakciós szinteket mosunk össze (megsértjük a vertikális tagolást), ezzel kapcsolatban is van egy kifejezés, a tell don't ask.

Clean Code - Abszrakciós szintek, DRY (don't repeat yourself)

Néhány alapfogalmat bedobok a közösbe folytatólagosan mielőtt komolyabban belemennék a clean code-os dolgokba, ha már egyszer régen megígértem, hogy írok róla cikket. Az egyik az absztrakciós szintek fogalma.

Ez durván arról szól, hogy a magas szintű dolgok az emberi gondolkodásmódhoz állnak közel, az alacsony szintű dolgok meg a gépi gondolkodásmódhoz. Ez egy folytonos skála. Minden projekt lefejlesztése gyakorlatilag arról szól, hogy az absztrakciós szint különbséget áthidaljuk, ami fejlesztő és gép között van. Sokszor ebbe a sorba még becsatlakoznak további emberek, pl megrendelő, projekt menedzser, domain expert, illetve a program különböző részeinek a fejlesztői, szóval egy elég komplex gráf is kijöhet, ami mind arra irányul, hogy a fentről (magasabb absztrakciós szintről) érkező információt beépítsük a kódba.


Tőzsdei modellezős projekt - kezdetleges árfolyam- és kockázat modellek kialakítása

A Tőzsdei befektetések olvasgatása mellett pont most néztem meg gondolatébresztő programozással - konkrétan BDD-vel - kapcsolatos videót (10 years of Doing Behaviour-Driven Development All Wrong by Liz Keogh). Ebben a linkelt résznél van egy szép ábra, ami azt mondja, hogy egy programozási projektnél a fő befektetője a projektnek (primary stakeholder) általában úgy fektet be, hogy van neki egy nagy álma (vision). Ha jóféle befektetésről van szó, akkor ez az álom nagyjából kimerül valami olyan dologban, ami pénzt hoz (makes money), megtakarít (saves money) vagy megvédi a pénzt (protects money). Maga az előadás egyébként nem valami izgalmas, de ez a része kicsit továbbgondolva jó kiindulási alap egy tőzsdei modell felállításához, mint az a későbbiekből ki is fog derülni.

Könyvajánló - Kecskeméti István: Tőzsdei befektetések


Egy ideje már agyalok a tőzsdén, olvasgattam is a témában Kecskeméti István alapművét a Tőzsdei befektetések című cirka 250 oldalas kis szösszenetet. Nem egy könnyed esti olvasmány, de ha az ember hallgatott már valamelyik felsőoktatási intézményben gazdaságtannal kapcsolatos előadást, akkor tudja, hogy van még sokkal de sokkal lejjebb. Én konrétan kimentem 10 perc után, mert azt hittem ott helyben elalszom.

1. ábra - így néz ki kívülről - forrás

Maga a könyv nagyon hasznos dolgokat tartalmaz, de atomszáraz. Hónapokba telt, amíg átvergődtem rajta magam. Gyakorlatilag tőzsdei indikátorok felsorolása az egész, szóval inkább egy szótárhoz vagy programozós dokumentációhoz hasonlítható, mint egy írott könyvhöz, de annyi baj legyen, olvastam én már ilyet pl a Refactoring to patterns vagy a Design patterns programozási alapművek is hasonlóak, csak egy fokkal érdekesebbek a konkrét példák sokszínűsége miatt.

Néhány alapgondolatba is bevezet a könyv a befeketetői bizalommal kapcsolatban. Konkrétan azt hozza le, hogy Japánban az 1700-as években egy Homma nevű rizs kereskedő felismerte, hogy a rizs eladási árát nem csak az áru értéke (amit a kereslet és a kínálat határoz meg), hanem a kereskedők hangulata is erősen befolyásolja. Ebből alakult ki később a japán gyertyás elemzés, amit a mai napig használnak.

Egyébként megérte elolvasni, leginkább az utolsó oldalak miatt, azokon van egy konkrét kereskedés kockázat kezeléssel mindennel együtt, ami nagyon sokat mond arról, hogy hogyan lehet mindezt biztonságosan csinálni. Az indikátorok is érdekesek, talán ha mindent figyelembe veszünk, akkor nagy tapasztalattal 90%-os biztonsággal le lehet kereskedni azok alapján is egy részvényt. Ezt az értéket megdobja a kockázat kezelés, ami meg arra jó, hogy ne veszítsünk sokat, és amit nyertünk azt megvédjük. Egyáltalán nem tűnnek ezek alapján tippmix szintűnek a tőzsdei befektetések. Nyilván akik indikátorok helyett bennfentes tippekre támaszkodnak a kereskedésben, azoknak nem megy a dolog, dehát ez meg pont nekünk jó, mert tőlük vesszük el a pénzt.


Revival - az újjászületés

Úgy döntöttem, hogy megreformálom ezt a blogot, és a régi - csak programozással foglalkozó - blog helyett valami teljesen újat csinálok inkább. Sok féle témával foglalkozom a programozáson kívül, és ezekről is fogok ezentúl rövid bejegyzéseket közzétenni.

Ezzel kapcsolatban töröltem néhány régi blog bejegyzést, amelyeknek nem tetszett a stílusa, és egyébként sem volt sok értelme megírni őket így utólag. A bejegyzések terjedelmét megszabom max 5 oldalban képestül mindenestül. Nem szeretnék újra abba a hibába esni, hogy túl hosszú bejegyzéseket írok. Csak az időm megy vele, és egyébként sem kedvelik az olvasók az ilyeneket, mert már könyv kategória. Nyilván ez a részletesség rovására fog menni. Ennek ellensúlyozására be fogok iktatni releváns linkeket, amelyek valószínűleg angol nyelvűek lesznek, illetve ha nagyon muszáj, akkor szétszedem több bejegyzésre a mondandómat. Ennyit tudok tenni az ügy érdekében.

A  mostani angol nyelvű címkés rendszer marad. Általában az angol a szaknyelv az olyan témáknál amik foglalkoztatnak. Akinek ez a probléma, az pillanatok alatt utána tud nézni a legtöbb címkének szótárban, hogy mit jelent.

Valószínűleg a következő néhány hónapban nagyon sűrűn fogok írni az olyan témákról, amikről szerettem volna cikket írni az elmúlt néhány évben, amíg szüneteltettem a blogot, de nem jött össze a publikálás, vagy éppen megszűnt az oldal, ahova be akartam küldeni a cikket, és így tovább. Meguntam ezt a trendet, és úgy döntöttem, hogy a saját kezembe veszem az irányítást. Ez az időszak várhatóan nyárra lezárul, és utána maradok majd a heti egy-két bejegyzésnél, esetleg még ennél is ritkábban írok, ha nincs friss info.