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.