2009-ben vettem egy hanlin típusú ebook readert. Akkor elég borsos ára volt, ha jól emlékszem majdnem 80ezer forint. Sokáig bírta, igazából még most is működik, csak nem lehet már aksit kapni hozzá, folyamatosan töltőn kell tartanom. Meg a borítója lefoszlott.
A halál oka 1: csere alkatrészek hiánya
2012-ben vettünk egy Kindle olvasót. 2015-ben a newcastle-i repülőtér biztonsági ellenőrző röntgene kinyírta. Úgy tűnik ilyen van, ugyanakkor a fenti hanlin kibírta ugyanazt a röntgent.
A halál oka 2: röntgen
A megöregedett hanlin readerem lehelyettesítésére leptem meg magam egy PocketBook Aqua readerrel. Az extra benne az, hogy víz- és nyálvédett. A bosszantó benne az, hogy töcskscreen-es. Erre rájöttem, hogy egy ebook readeren ez nemcsak haszontalan, de bosszantó is. Nem volt különösebben sok alkalma arra, hogy a vízállóságát bizonyítsa, egyetlen egyszer nem ázott meg. Fogalmam sincs mi történt vele, egy átszállás elött még működött, utánna már nem.
A halál oka 3: Hauptbahnhof
Ennyit a hardware minőségéről, a szoftver általában sokkal bosszantóbb. Mindegyik típusnak megvan a maga betegsége, néha lefagynak.
Szóval bár 2009-10 körül azt mondtam, hogy optimistán látom a technológia jövőjét: néhány év tapasztalattával már kicsit más, teljesen elment tőle a kedvem hogy akár csak még egy ilyen eszközt vegyek.
Amúgy az ára nem lenne vészes, de a minősége az sajnos gáz.
2017. december 14., csütörtök
2017. október 20., péntek
Informatika oktatás
István írására egy komment...
Ezt csak összehasonlításként mondanám el, mert a középiskolai szintű oktatást én sem tartom alkalmasnak arra, hogy szoftverfejlesztőket képezzen.
Középiskolába infós szakra jártam, nekünk volt valamiyen tantárgy, ahol elmondták az összes rendezési algoritmust, kereséseket, és pl a backtrack algoritmust, ami rémesen egyszerű, majdnem primitív. Kb 20 perc alatt mondta el a tanár az órán ismétlésekkel együt, utánna mindenkinek kellett egy példafeladatot megoldania a backtrackkel (válaszhatsz labirintus vagy a 8 királynő közül), utánna mindenkinek ment, egymásnak is el tudtuk magyarázni, semmi nehézség.
Évekre meg is feledkeztem az egészről, egész addig amig be nem íratkoztam ELTE progmat esti tagozatára. Progmaton pedig Fóti tanárúr szánt rá az "Bevezetés a programozáshun" elméleti előadásokból egy egész estényit, az egész fejezetnek ez volt a címe, hogy "Backtrack". Absztrakt számrendszerekkel kezdte, aztám a korábban megismert állapotterekre fordította le a témát, majd végül felírta a backtrack csodálatos matematikai definícióját, alig 2 óra alatt. Eközben mindenki szorgosan jegyzetelt, de ráncolt homlokok és a ködös tekintetek mögött látszott, hogy az emberek egyetlen kérdése a témával kapcsolatban egy általános "WTF". Az előadás után néhány embert megkérdeztem, hogy hol vetnék be a backtrack algoritmust. A reakció volt érdekes, mert a legtöbb embernek nem esett le, hogy itt most valami olyat hallottunk, amit bármire is be lehetne vetni, páran mondták csak azt, hogy "hú, azt még nem tudom".
Ha ismered egyébként a "Bevezetés a programozáshól" 1-6 tárgyat, akkor ezen talán nem lepődsz meg. Sok vita tárgya, de azt hiszem a legtöbben egyetértenek abban, hogy a hétköznapi szoftverfejlesztés gyakorlatától távolabb áll, mint a művészettörténelem.
Végeztem még egy pár kisérletet, és egyébként informatikában és algoritmuselméletben nem jártas embereknek (például édesanyámnak) elmagyaráztam az algoritmust, nyilván nem írattam velük ZH-t vagy gyakorló programot, de megkérdeztem, hogy pl milyen feladatra lehetne ezt a módszert bevetni. A magyarázat kb 2 percet vett igénybe, és működött.
Tehát nem kalapácsot adnak a kezünkbe, hanem megtanítanak gondolkozni... Igen, látom hogy kalapács nincs, de gondokodni megtanultunk vajon? Vagy komplkálni tanultunk meg? Vagy az ugyanaz? Vagy csak hisszük, hogy ugyanaz? Vagy most mi van?
A gyakorlati téren, már amennyire van gyakorlati oldala az ELTE progmatnak, sokkal kiábrándítóbb tapasztalataim voltak. Például egy C++ zárthelyin a leadáskor kellett megpróbálnom elmagyarázni a tanárnak, hogy mi a unit teszt (a kérdésére, hogy mit lát a képernyőn). Feladta és elmenekült, de itt nem volt vége, a következő tanárnak azt kellett elmagyaráznom, mi a standard input stream. Ezt követően egyetértésben nullásra értékelték a ZH-mat, pedig addig nem mutattam jelét annak, hogy szivesen feldarabolnám a két barmot.
Nem ott és azonnal, de hasonló esetek sora lassan leamortizálta a türelmemet. Munkám nyilván volt már, egyébként nem tudtam volna kipengetni a tandíjat. A pénzt nem sajnálom, de az időmet nagyon.
De egyetértek Istvánnal: ha van rá pénzed, menjél egyetemre. Tanuld meg, felejtsd el! Ez egy jó gyakorlat. Mi mást csinálnál 18-19 évesen? :-)
Hajrá!
Ezt csak összehasonlításként mondanám el, mert a középiskolai szintű oktatást én sem tartom alkalmasnak arra, hogy szoftverfejlesztőket képezzen.
Középiskolába infós szakra jártam, nekünk volt valamiyen tantárgy, ahol elmondták az összes rendezési algoritmust, kereséseket, és pl a backtrack algoritmust, ami rémesen egyszerű, majdnem primitív. Kb 20 perc alatt mondta el a tanár az órán ismétlésekkel együt, utánna mindenkinek kellett egy példafeladatot megoldania a backtrackkel (válaszhatsz labirintus vagy a 8 királynő közül), utánna mindenkinek ment, egymásnak is el tudtuk magyarázni, semmi nehézség.
Évekre meg is feledkeztem az egészről, egész addig amig be nem íratkoztam ELTE progmat esti tagozatára. Progmaton pedig Fóti tanárúr szánt rá az "Bevezetés a programozáshun" elméleti előadásokból egy egész estényit, az egész fejezetnek ez volt a címe, hogy "Backtrack". Absztrakt számrendszerekkel kezdte, aztám a korábban megismert állapotterekre fordította le a témát, majd végül felírta a backtrack csodálatos matematikai definícióját, alig 2 óra alatt. Eközben mindenki szorgosan jegyzetelt, de ráncolt homlokok és a ködös tekintetek mögött látszott, hogy az emberek egyetlen kérdése a témával kapcsolatban egy általános "WTF". Az előadás után néhány embert megkérdeztem, hogy hol vetnék be a backtrack algoritmust. A reakció volt érdekes, mert a legtöbb embernek nem esett le, hogy itt most valami olyat hallottunk, amit bármire is be lehetne vetni, páran mondták csak azt, hogy "hú, azt még nem tudom".
Ha ismered egyébként a "Bevezetés a programozáshól" 1-6 tárgyat, akkor ezen talán nem lepődsz meg. Sok vita tárgya, de azt hiszem a legtöbben egyetértenek abban, hogy a hétköznapi szoftverfejlesztés gyakorlatától távolabb áll, mint a művészettörténelem.
Végeztem még egy pár kisérletet, és egyébként informatikában és algoritmuselméletben nem jártas embereknek (például édesanyámnak) elmagyaráztam az algoritmust, nyilván nem írattam velük ZH-t vagy gyakorló programot, de megkérdeztem, hogy pl milyen feladatra lehetne ezt a módszert bevetni. A magyarázat kb 2 percet vett igénybe, és működött.
Tehát nem kalapácsot adnak a kezünkbe, hanem megtanítanak gondolkozni... Igen, látom hogy kalapács nincs, de gondokodni megtanultunk vajon? Vagy komplkálni tanultunk meg? Vagy az ugyanaz? Vagy csak hisszük, hogy ugyanaz? Vagy most mi van?
A gyakorlati téren, már amennyire van gyakorlati oldala az ELTE progmatnak, sokkal kiábrándítóbb tapasztalataim voltak. Például egy C++ zárthelyin a leadáskor kellett megpróbálnom elmagyarázni a tanárnak, hogy mi a unit teszt (a kérdésére, hogy mit lát a képernyőn). Feladta és elmenekült, de itt nem volt vége, a következő tanárnak azt kellett elmagyaráznom, mi a standard input stream. Ezt követően egyetértésben nullásra értékelték a ZH-mat, pedig addig nem mutattam jelét annak, hogy szivesen feldarabolnám a két barmot.
Nem ott és azonnal, de hasonló esetek sora lassan leamortizálta a türelmemet. Munkám nyilván volt már, egyébként nem tudtam volna kipengetni a tandíjat. A pénzt nem sajnálom, de az időmet nagyon.
De egyetértek Istvánnal: ha van rá pénzed, menjél egyetemre. Tanuld meg, felejtsd el! Ez egy jó gyakorlat. Mi mást csinálnál 18-19 évesen? :-)
Hajrá!
2017. október 9., hétfő
checklist project indításhoz
Pár dolgot összeírtam, amit az ember bán az egész projekt során hogy nem lett meg a legelején. Nem vagyok én se híve a sok pöcsölésnek, de ismeritek azt a mondást, hogy...
Hát szóval...
Ezen már évek óta sokat bosszankodok, hogy hogyan lehet ilyet bénázni, de sok megörökölt projektemen egyszerűen totál másmilyen volt a teszt schema a prod schemához képest és az embereknek olyan ködös elképzeléseik voltak hogy "A DBA nem tudja másolni a teszt schemát amikor upgradelünk?"
Annyi tennivaló marad, hogy azokat az igazhitű junixereket, akik vimmel meg emacs-szel akarnak szoftvert fejleszteni, szóval őket egy tompa nehéz tárgyal jobb belátásra téríteni.
Aztán még a space-nácik és az alternatív tab-pártiak összecsapását is gyorsan helyre kell tenni, de ehhez a tompa nehéz tárgy helyett inkább valami gyorsan használhatót ajánlanék, pl lángszóró.
Persze mostanában dolgoztam olyan kollágával is, aki eltörte a tesztet és írt egy levelet, hogy "a junit teszt nem működik, javítsd már meg" Ezek ilyen kultúrális kompatibilitási problémák.
Pl hogy beéred-e egy gyors jetty-vel a fejlesztőkörnyezetben vagy muszáj legyen megvárni, hogy a websphere felemelje a seggét, esetleg elég ha a tesz környezet websphere...
Hogyan bánjunk a ránk kényszerített közös MQ-val, közös adatbázissal.
Ezeknél szokott elcsesződni a produktívítás, amikor hosszú perceket várhatsz egy buildre. Vagy pl sokan másolgatnak fileokat a dev folder és a webszerver között. Ez nekem már 2000-ben is a rühes 90-es évek maradványának tűnt.
Biztos van még sok, csak most nem jut eszembe, legyen akkor csak ennyi most.
Néhány hét kemény munkával több órányi tervezést meg lehet takarítani.
Hát szóval...
Első helyezet: Adatbázis schema verziózás
Kár vitatkozni hogy, old school liquibase vagy az újabb flywaydb, a saját buherált script is csak ritkán rosszabb a semminél :)Ezen már évek óta sokat bosszankodok, hogy hogyan lehet ilyet bénázni, de sok megörökölt projektemen egyszerűen totál másmilyen volt a teszt schema a prod schemához képest és az embereknek olyan ködös elképzeléseik voltak hogy "A DBA nem tudja másolni a teszt schemát amikor upgradelünk?"
Erős második: forráskód formázó beállítások
Csodálatos módon az eclipse és az intellij értik egymás kódformázó beállításait. Pontosabban az intellij érti az eclipse-t, az eclipse meg jobbára érti önmagát.Annyi tennivaló marad, hogy azokat az igazhitű junixereket, akik vimmel meg emacs-szel akarnak szoftvert fejleszteni, szóval őket egy tompa nehéz tárgyal jobb belátásra téríteni.
Aztán még a space-nácik és az alternatív tab-pártiak összecsapását is gyorsan helyre kell tenni, de ehhez a tompa nehéz tárgy helyett inkább valami gyorsan használhatót ajánlanék, pl lángszóró.
Bronzérem: CI enforce tests
Amikor már fél éve törött egy teszt és senkit nem érdekelt, így ment élesbe akkor már igazán késő sajnálkozni.Persze mostanában dolgoztam olyan kollágával is, aki eltörte a tesztet és írt egy levelet, hogy "a junit teszt nem működik, javítsd már meg" Ezek ilyen kultúrális kompatibilitási problémák.
Negyedik: DEV produktívítás
Szerintem érdemes valami egyezségre jutni, vagy megpróbálni egyezségre jutni, hogy milyen eszközöket használunk és azokkal mekkora overhead-et kap az egész fejlesztés. Amikor egy tool már bent van, akkor már késő, az többnyire ott marad.Pl hogy beéred-e egy gyors jetty-vel a fejlesztőkörnyezetben vagy muszáj legyen megvárni, hogy a websphere felemelje a seggét, esetleg elég ha a tesz környezet websphere...
Hogyan bánjunk a ránk kényszerített közös MQ-val, közös adatbázissal.
Ezeknél szokott elcsesződni a produktívítás, amikor hosszú perceket várhatsz egy buildre. Vagy pl sokan másolgatnak fileokat a dev folder és a webszerver között. Ez nekem már 2000-ben is a rühes 90-es évek maradványának tűnt.
5: contact list
Egy egész sor projecten dolgoztam úgy, hogy vakon mentünk. Fogalmunk sem volt, hogy ki a felhasználó, ki a DBA, ki fogja a support feladatokat ellátni, és nyilván hogy ők hogyan szeretnének velünk együt dolgozni. Egy ilyennel garantált a későbbi probléma.Biztos van még sok, csak most nem jut eszembe, legyen akkor csak ennyi most.
2017. április 22., szombat
ki profitált a kerub-ból idáig...
Mivel intenzíven használok pár szoftvert, bugreportok és patchek formájában néhány project már profitált abból, hogy a vonaton munkába menet nem csak a tájat nézem. Pár közűlük, amikre emlékszem:
Már csak azért is meg akartam ezeket a projekteket említeni pozitív példaként, mert negatív példa is akad bőven az OSS projectek között.
- Jetty és CXF bugreportok, ezek a csákók igazán rendesek voltak és pár nap alatt kijavította mindkét csapat a hibákat.
- Shiro bugfix
- Kotlin - többnyire apróságok a stdlib-ben, egyszer egy apróság a compilerben, párszor az IDE-ben.
- Infinispan bugreportok - bár utóbb rájöttem hogy nem érdemes sietni az infinispan upgradekkel mert a release után úgyis találnak pár hibát és kiadnak rá egy javítást. Egy kis türelem sok időt megtakarít.
Már csak azért is meg akartam ezeket a projekteket említeni pozitív példaként, mert negatív példa is akad bőven az OSS projectek között.
2017. április 10., hétfő
Sky job interview
Egyszer, amikor a brexit még a posztapokalpitikus sci-fi horrorpornókomédia kategóriába tartozott, voltam a Sky tévétársaságnál állásinterjún. Az jutott most eszembe, hogy ettől esetleg megmentselek titeket :-D
Elég nagyipari mennyiségben hívták be az embereket, délre kellett odaérni és a portán nyolcan ültünk az időpontban, azt hiszem 2 nő, voltak környékbeliek és távolabbról érkezők, fehérek és feketék, idősebbek fiatalabbak, ufók és alienek. Szerencsére azért jó arcok voltak és szendvicseket lehetett választani. Az elején gyorsan elmagyarázta a HR-es arc a szabályokat, aki nem teljesít úgy, ahogy elvárnák, annak szólnak és mehet. Ez kellemetlenül hangzik, de végülis jobb egy délutánt várostnézni Londonban, mint még pár órát kuksolni egy cég irodájában. Egyébként elég hosszú procedúra volt. Ilyen körök voltak, hogy:
Elbúcsúztam és igyekeztem elkapni az utolsó repülőgépet hazafelé, akkor úgy tünt, minden oké. De aztán soha nem hívtak. Pár héttel később írtam a HR-es csókának, hogy gondolom hogy "nem" a válasz, csak érdekelne hogy miért.
Azt válaszolta, hogy mert nincs tapasztalatom a pair programmingban. Ez egyébként tényleg így is van, sehol nincs ilyesmi a CV-ben, de ez a válasz volt az, ami nogo listára tette nálam a sky-t, mert ezt így értettem:
Szóval azért, hogy a HR-es végül elolvassa a CV-t az interview után, azért szerintem kár kidobni a pénzt repülőjegyre.
Az átlagos ember a maga hibáiból tanul, ezt remélem kipipálhatom, ti meg próbáljatok jobbat :)
Elég nagyipari mennyiségben hívták be az embereket, délre kellett odaérni és a portán nyolcan ültünk az időpontban, azt hiszem 2 nő, voltak környékbeliek és távolabbról érkezők, fehérek és feketék, idősebbek fiatalabbak, ufók és alienek. Szerencsére azért jó arcok voltak és szendvicseket lehetett választani. Az elején gyorsan elmagyarázta a HR-es arc a szabályokat, aki nem teljesít úgy, ahogy elvárnák, annak szólnak és mehet. Ez kellemetlenül hangzik, de végülis jobb egy délutánt várostnézni Londonban, mint még pár órát kuksolni egy cég irodájában. Egyébként elég hosszú procedúra volt. Ilyen körök voltak, hogy:
- pair programming egy önkéntes alkalmazottal
- valami kis problémamegoldás
- architektura design egy pár fazonnal whiteboard-nál
Elbúcsúztam és igyekeztem elkapni az utolsó repülőgépet hazafelé, akkor úgy tünt, minden oké. De aztán soha nem hívtak. Pár héttel később írtam a HR-es csókának, hogy gondolom hogy "nem" a válasz, csak érdekelne hogy miért.
Azt válaszolta, hogy mert nincs tapasztalatom a pair programmingban. Ez egyébként tényleg így is van, sehol nincs ilyesmi a CV-ben, de ez a válasz volt az, ami nogo listára tette nálam a sky-t, mert ezt így értettem:
Kedves Izé,
Miután eljöttél az interview-ra, végre elolvastam a CV-d és akkor jövök rá: baszod te egyáltalán nem is vagy édzsájl! Valamiért azt hittem hogy na mindegy...
Dögölj meg,
HR
Szóval azért, hogy a HR-es végül elolvassa a CV-t az interview után, azért szerintem kár kidobni a pénzt repülőjegyre.
Az átlagos ember a maga hibáiból tanul, ezt remélem kipipálhatom, ti meg próbáljatok jobbat :)
2017. március 6., hétfő
kerub - a packaging frontról jelentjük
Kerub. Kicsit megint hanyagoltam a blogolást, de a munkára igyekeztem időt szorítani. A nagyobb dolgok amikbe belerúgtam mostanában:
Na jó, ennyi bőven sok, dolgozzunk!
- yum/dnf repok CentOS 7-hez és Fedora 23-hoz. yum (vagy dnf) install után a kerub elindul és megy ugyanúgy, mint a fejlesztőkörnyezetben. A házi jenkins buildjei fel is küldik minden változtatás után a friss RPM-eket.
Készül az Ubuntu és a Debian csomagoló is.
A csomagokról annyit el kell mondanom, hogy bár amennyire tudom, korrekt módon csomagolok (nem kell kikapcsolni a selinuxot, lecsapni a firewallt, stb), a disztrók csomagolási útmutatóját egyszerűen betarthatatlannak találom és figyelmen kívül hagyom. Konkrétan az, hogy az infinispant és a jgroups-ot is rpm csomagokból oldjam fel a WEB-INF/lib helyett, az esélytelen.
Ezt alighanem más is így találta, mert a disztrók összesen 0 db java webalkalmazást tartalmaznak. A kerub se lesz benne soha.
A csomagolás egyébként olyan, mintha az apolló űrhajót mamutbőrbe - Egy teljesen új projectet kezdtem integrációs tesztekhez. Bár egész sok integrációs teszt található a fő projektben, ami simán a maven embedded jetty-jével elszalad, ezek nem képesek olyan eseteket lefedni, mint pl cluster, de akár még olyat sem, hogy virtuális gépben futó "host", mert futniuk kell jenkinsben, a linuxos desktopomon, travis-ban, meg a halál répáján.
Az új projekt ilyen integrációs teszteket tartalmaz, csinál egy virtuális gépet, feltelepíti a kerub webappot, tesz elé load balancert, ad hozzá hostokat, feltölt egy virtuális merevlemez imaget, elindít egy virtuális gépet, satöbbi.
Nyilván ez úgy magában is elég lassú lesz, úgyhogy karrier szempontokat szem elött tartva úgy gondoltam ez most had legyen groovy-ban. Grooovy!!! - Már majdnem ott tartok, hogy a web**cket biztonsági teszteket befejezzem. Hozzá kell tennem persze hogy nem csak a tesztekről van szó hanem konkrétan az implementációról is :-D
Na jó, ennyi bőven sok, dolgozzunk!
2017. január 10., kedd
IT szegregáció
Középiskolában kb 20 fős osztályban volt 5 lány, ez talán még ma sem számítana egy döbbenetesen rossz aránynak egy informatikai középiskolában. Az 5 lányból 4 alkotta az osztályelsők csoportját, ők mindenből jók voltak. Ennek ellenére az utolsó év végén a szak egyik vezető tanára az értékelésben elmondta, hogy bár ez nagyon szép eredmény, ez egy "férfi szakma".
Ezt lehet úgy is nézni, hogy persze ez is egy vélemény, de ezek tizenéves lányok voltak és szerintem komolyan szivükre vették. Csak ültünk és kussoltunk, ahogy szoktuk, senki nem kérdezte hogy mire gondol, kell-e 50 kilós szervereket felcipelni a tizedikre gyalog, vagy tettlegességig elmenni a singleton pattern feletti vitában.
A másik iskolai élményem a témában az ELTE-ről Lakatos László tanárúr munkássága, aki matematika gyakorlatot tartott akkoriban. Ő egy ijesztően furcsa alak, az elejétől a végéig görcsösen vigyorgott órákon, szúrós megjegyzéseket tett a hallgatókra általában de a lányokra határozottan rászállt. Ribancnak és suttyónak nézett mindenkit és nem tartotta vissza a véleményét, én valamennyire megszoktam azokat, akik nincsenek magas véleménnyel rólam, de a lányok máshogy viszonyultak ehhez. Egész kemény csajok jártak az esti szakra, de az első félév második felére már egyetlen lány se járt be az óráira, kénytelen volt minket szórakoztatni olyan kérdésekkel, mint hogy biztosan százezreket fogunk keresni (höhh...), milyen fasza autónk lesz, mert a suttyókat mivel lehetne ugratni.
Nálam már messze túl lenne a határon az amit ő csinált, de az ELTE-nek ez a 2000-es évek elején még teljesen oké volt, meg ahogy nézem a kar dolgozóinak névsorát még most is az.
Azt hiszem ennyi elég is lenne ahhoz, hogy ne csodálkozzunk a helyzeten.
Munkahelyen nagyon ritkán dolgozok együtt szoftverfejlesztő nőkkel. Legutóbb az előző munkahelyemen ült mellettem egy lány néhány hónapig. Ő szándékán kívül a külsejével nagy figyelmet vont magára. Illetve hagyjuk ezt az érthetetlen hiper-korrektséget, egyszerűen nagy mellei voltak, ez egyszerűen matematikai tény. Érdekes volt, hogy mennyi hülyét vonzott oda. Persze voltak normálisan barátai is, de jöttek rá a hülyék, és bár egyébként barátságos nő volt, időnként határozottan el kellett küldenie valakit a halál farkára. Úgy tűnik, ez a képesség nőknek alapfeltétel a túléléshez a szakmában.
Szóval annyira nem lehet frankó nőként ezt a szakmát hajtani, de lehet másikat se könnyebb.
Ötletek a korrekcióra...
Szerintem nem csak a nők kedvéért, hanem a magunkért is, visszább kellene venni a munka kocsmai verekedés jellegéből. Nekem sincs hozzá semmi kedvem.
Talán már iskolákban tisztázni kellene, hogy a munkahelyi csajozás nem annyira pöpec ötlet.
Az, hogy külön közösségeket és cégeket hozzanak létre nőknek, az nekem teljesen abszurd.
Ezt lehet úgy is nézni, hogy persze ez is egy vélemény, de ezek tizenéves lányok voltak és szerintem komolyan szivükre vették. Csak ültünk és kussoltunk, ahogy szoktuk, senki nem kérdezte hogy mire gondol, kell-e 50 kilós szervereket felcipelni a tizedikre gyalog, vagy tettlegességig elmenni a singleton pattern feletti vitában.
A másik iskolai élményem a témában az ELTE-ről Lakatos László tanárúr munkássága, aki matematika gyakorlatot tartott akkoriban. Ő egy ijesztően furcsa alak, az elejétől a végéig görcsösen vigyorgott órákon, szúrós megjegyzéseket tett a hallgatókra általában de a lányokra határozottan rászállt. Ribancnak és suttyónak nézett mindenkit és nem tartotta vissza a véleményét, én valamennyire megszoktam azokat, akik nincsenek magas véleménnyel rólam, de a lányok máshogy viszonyultak ehhez. Egész kemény csajok jártak az esti szakra, de az első félév második felére már egyetlen lány se járt be az óráira, kénytelen volt minket szórakoztatni olyan kérdésekkel, mint hogy biztosan százezreket fogunk keresni (höhh...), milyen fasza autónk lesz, mert a suttyókat mivel lehetne ugratni.
Nálam már messze túl lenne a határon az amit ő csinált, de az ELTE-nek ez a 2000-es évek elején még teljesen oké volt, meg ahogy nézem a kar dolgozóinak névsorát még most is az.
Azt hiszem ennyi elég is lenne ahhoz, hogy ne csodálkozzunk a helyzeten.
Munkahelyen nagyon ritkán dolgozok együtt szoftverfejlesztő nőkkel. Legutóbb az előző munkahelyemen ült mellettem egy lány néhány hónapig. Ő szándékán kívül a külsejével nagy figyelmet vont magára. Illetve hagyjuk ezt az érthetetlen hiper-korrektséget, egyszerűen nagy mellei voltak, ez egyszerűen matematikai tény. Érdekes volt, hogy mennyi hülyét vonzott oda. Persze voltak normálisan barátai is, de jöttek rá a hülyék, és bár egyébként barátságos nő volt, időnként határozottan el kellett küldenie valakit a halál farkára. Úgy tűnik, ez a képesség nőknek alapfeltétel a túléléshez a szakmában.
Szóval annyira nem lehet frankó nőként ezt a szakmát hajtani, de lehet másikat se könnyebb.
Ötletek a korrekcióra...
Szerintem nem csak a nők kedvéért, hanem a magunkért is, visszább kellene venni a munka kocsmai verekedés jellegéből. Nekem sincs hozzá semmi kedvem.
Talán már iskolákban tisztázni kellene, hogy a munkahelyi csajozás nem annyira pöpec ötlet.
Az, hogy külön közösségeket és cégeket hozzanak létre nőknek, az nekem teljesen abszurd.
2017. január 1., vasárnap
lights out
A desktop-gagyi
A legtöbb PC, még a nyomi kis NUC is tartalmaz egy Wake ON Lan nevű feature-t. Ez elég egyszerű, egy UDP broadcastot kell küldeni a hálózatra, legyen benne egy speciális header és utánna 6-szor megismételve Csipkerózsika MAC address-e. Lássanak csodát, Csipkerozmária felébred és bootolni kezd... ha engedélyezve van ez a BIOS-ában persze.A nyilvánvaló hátrányok:
- akárki megcsinálhatja, semmilyen azonosítás nem kell hozzá
- csak a helyi hálózaton működik mert a router valószinűleg eldobja
- semmilyen választ nem kapsz róla
- megbízhatatlan, pl ha kihúzod a dugót és visszadugod, lehet hogy nem kapcsol be újra egészen egy teljes indításig
A gáz...
Szervereknél elterjedt szabvány az IPMI. Ez majdnem minden szerverben megvan - illetve a OpenCompute minimalista cuccokban alighanem nincs, de olyan senkinek sincs.Az IPMI nem csak arra jó, hogy ki-be kapcsolgasd a szervert, tudsz vele:
- konzolhoz csatlakozni
- sensor információkat olvasni
- akár boot médiumot is feltölteni - például erről már szivesen lemondanék
- UDP - vajon miért?
- Sajnos nem biztonságos, és a világon mindent meg lehet vele csinálni (lásd fent)
- A legtöbb vendor egy kis java applettel teszi hozzáférhetővé - ne tessék... java applet 2017-ben!!!
A trendi
Az IPMI trónfosztására készül egy RedFish nevű specifikáció. Ez egy REST, http + JSON alapú dolog, amihez egyszerű akármilyen klienst fabrikálni. Elég érdekes, például lehet vele blade szervereket is buherálni, egyetlen management felület ad hozzáférést az összes blade-hez. A hátrányait még senki sem ismeri, annyira új, de nyilván emiatt csak újonnan lehet beszerezni, tesztelésre és fejlesztésre ez kicsit talán drága nekem. Az az ötlet, hogy egy szoftveres megoldással helyettesítem, egy vagy több VM-et indítana el libvirt-en keresztül, de végül úgyis igazi hardverrel kellene tesztelni. Sebaj, majdcsak megszán valaki...Helyzet
Szóval a következő években érkező új szerver típusok többnyire redfish-sel érkeznek majd, de ott lesz rajtuk az IPMI is, mert azt mindenki ismeri és támogatja. Gyanús, hogy nem lehet választani, hogy csak redfish legyen vagy IPMI. Van az alaplapon egy jumper, azzal lehet kikapcsolni a teljes BMC-t, akkor nem lesz egyik se.Az oVirt-ben például ez úgy történik, hogy a management szerver egy host-ot kér meg, hogy az ébressze fel a másik hostot. Nyilván legalább egy hostot mindig ébren kell tartani, de nem ez a kifogásom ellene. Nem tetszik az at ötlet, hogy a hostok számára elérhetővé teszik a management interface-t, túl nagy felületet ad a támadásra.
A kerub-ban inkáb a kontrollert akarom használni erre a célra, ehhez viszont írnom kell egy minimalista IPMI klienst, valamint a fenti redfish dev env szintén nagyon jó lenne... Jó sok meló lesz, lássunk hát hozzá :)
Boldog buékot.
Feliratkozás:
Bejegyzések (Atom)