Azt hittem a “hosszú” fájlnevek problémája csak az emlékeimben él, és a minket követő generációk számára ez a fogalom (akárcsak a ~1 végű fájlok) ismeretlen lesz. Úgy tűnik a Windows ezt másképp gondolja, Ő még őrzi a régi hagyományokat:
Én tényleg nem tudom ki, és mit üzemeltet windows alatt, de minden tiszteletem az övé…
Nem titok, hogy az IT területen mozgó emberek a legtöbb céges eseményt kicsit másképp élik meg, mint más területen dolgozó kollégáik. Nem kivétel ez alól a céges karácsony sem. Az általános IT-s karácsony élményt vau tökéletesen összefoglalta, a céges karácsonyi buli című írásában.
Mivel abban a szerencsés helyzetben vagyunk, hogy nálunk szinte mindenki az IT területen dolgozik, adott volt a lehetőség, hogy olyan karácsonyi bulit szervezzünk, ami nekünk IT-soknak tetszik. A játszunk számítógépes játékkal alapvetést nem akartam én kijátszani, mégiscsak játékfejlesztésből kerültem a vállalati szektorba, és a világért sem szerettem volna a saját érdeklődési körömet ráerőltetni másokra. Szerencsére más irányból is felmerült ez az ötlet, és ha már így alakult nem is volt kérdés, hogy belevágjunk a projektbe.
A döntés megszületése után az első problémát maga a játék kiválasztása jelentette. Skill-t követelő játék nem nagyon jött szóba, hiszen mind játéktapasztalatban, mind korban nagyon nagy volt a szórás.
Végül a választás a Bomberman ’93 nevű klasszikusra esett. Az irányítása egyszerű, bármin elfut, és lehet egyszerre 4-en játszani.
Hogy senki ne tegyen jelentős előnyre szert, magát a játékot egészen a kezdésig titokban tartottuk. A játék, irányítás bemutatására készült egy rövid prezetnáció, de aki ezt mellőzni szeretné, használhatja az eredeti kézikönyvet is:
A fordulókat kétfős csapatokkal játszottuk, melyek kialakítása során az volt a feltétel, hogy a csapattársnak egy másik területről kell jönnie. Ez okozott némi kavarodást, de abban bíztam, hogy ezáltal nem lesznek túl erős csapatok, hiszen a csapattársak kevésbé ismerik egymást, és a cégen belül is felpezsdül a területek közötti kommunikáció. A csapatok kialakítására egy egyszerű Google Sheets-et használtam. A szükséges ellenőrzési logikát (validateTeamData) pedig megírtam gscript-ben. Nem lett hibátlan, de a célnak tökéletesen megfelelt.
Mivel a játék turbografx-16-on jelent meg, így a választott emulátor a mednafen lett, retroarch alól futtatva. Még meg kellett oldani az irányítást, amire eredetileg usb-s nes controllereket szerettem volna beszerezni, de a létszámra, és az idő rövidségére való tekintettel ezt végül elvetettem. Maradt az 1 gép, 1 monitor, 2 billentyűzet felállás, billentyűzetenként két játékossal.
A billentyűzetek controllerként viselkedjenek két dologra volt szükség: a vJoy-ra ami mint neve is mutatja virtuális joystick vezérlőket gyárt, és a Virtual Controller-re, amivel a virtuális joystick-okat a billentyűzetek bemenetével lehet etetni.
Szerencsére az egyszerű vezérlés miatt (4 irány 1 gomb) a vJoy beállítások nem lettek valami túl bonyolultak:
A Virtual Controller kapcsán már kicsit összetettebb a dolog:
A kész beállítások tesztelhetők a Monitor vJoy alkalmazással:
Sajnos a RetroArch konfigurálás nem volt olyan egyszerű mint elsőre gondotlam, ugyanis else if van a retroarch binding kódjában. Tehát ha kapott billentyűzet inputot, akkor már nem nézte a joystick inputot. A megoldás végülis az lett, hogy készítettem egy mapping-et a Virtual Controllerben Xbox 360 controllerhez vJoy-ra, ezzel már tudtam menteni a vJoy beállításokat a RetroArch-ba. Még 3x megismételni a beállítást nem sok kedvem volt, ezért a többi játékos esetén már kézzel szerkesztettem a config-ot a retroarch.cfg-be. Ezen felül törölni kellett minden bind-ot (az F1 és az ENTER kivételével), hogy a véletlen mellégépelésekből ne legyen probléma.
A Windows kapcsán a szokásos “gamer” beálllításokat kellett megtenni:
A csapatok állását a challonge.com-on vezettem, kicsit aggódtam is, mi lesz ha lehal a szerver, de szerencsére nem halt le.
A döntőt streamelni szerettük volna kommentátorokkal, de végül ez technikai okok miatt nem sikerült.
Persze mint minden ilyen rendezvénynél, itt is voltak technikai problémák, és olyan dolgok, amiket lehetett volna jobban csinálni. Iyenek pl.:
Az esemény a malőrök ellenére úgy gondolom jól sikerült, legalábbis elég sok pozitív visszajelzés érkezett. Örültem, hogy olyan menő kollégáim vannak, akik kortól / nemtől függetlenül ezt az egészet bevállalták. Szívbemarkoló volt a pillanat, mikor még a szabad játék alatt minden gép előtt ültek, és akik nem fértek oda a váluk fölött nézték, hogy ki hogy játszik, elemezték hogy mi a jó taktika. Tisztára mint egy retro számítógépes klubban.
Már csak ezért is megérte. No meg az érmekért…
(Mellesleg az éremmel sokat szívtam, mert a rajta látható képet nem volt egyszerű megtalálni… Az eredetit végül itt leltem fel, amiről még az izzadságcsepepket is le kellett varázsolni 🙂 )
Azt hittem, nagyon már nem fogok hozzányúlni a fűtéshez. Aztán véletlenül beleolvastam egy mézeskút (Honeywell) termosztát leírásába, ahol arról áradoztak, hogy annyira de annyira takarékos, és annyira menő, mert PI vezérlést használ, ami a legszuperebb.
Mivel én is menő és takarékos termosztátot szerettem volna, kicsit utána olvastam a dolgonak, és rá is találtam a Proportional Integral Derivative Control-ra, ami nem annyira bonyolult, mint amilyennek elsőre tűnik. Mint a neve is mutatja, derivál, integrál, ebből kitalálja (megjósolja), hogy mikor és mennyit kell fűteni, így nagyon precízen tudja tartani a beállított hőmérsékletet. Nagyjából így:
Akit érdekelnek a további részletek, az itt talál egy egész jó leírást, forráskódot, és további problémafelvetéseket (mint pl. tuning, derivative kick / filter, anti reset windup):
https://apmonitor.com/pdc/index.php/Main/ProportionalIntegralDerivative
A dolog annyira működik, hogy a bevezetés után az első visszajelzés az volt, hogy csináljam vissza az egészet, mert soha nem melegek igazán a radiátorok. Még különösebb tuningolás és különösebb görbeillesztések nélkül is, normál működés során elég észrevehetetlen mikor fűt, és mikor nem. Viszont a tényleges hőmérséklet tized foknál többel nem nagyon tér el az előre beállított értéktől.
A vezérlést egyébként épp a napokban módosítottam tovább, hogy a lenti részt csak akkor fűtse a rendszer ha a fentit amúgy is fűtené. Így önmagában a lenti ág csak végszükség esetén indul el, és sokkal melegebb is van, mintha külön fűteném. A fűtés hatásfoka nem észrevehető módon romlott (a plusz egy radiátor és padlófűtés cső nem sokat vesz el a visszatérő ágból, amit amúgy is felfűt a kazán).
A jövőben ha lesz még egy kis időm, akkor az újonnan érkezett szervómotorokból egyet rákötök a kazán hőmérséklet állító tekerőjére, és megpróbálom kihasználni a D részt a PID vezérlőből. Így majd az eltérés mértéke vezérli a kazán által előállított és keringetett víz hőmérsékletét. Ha csak picit kell fűteni, akkor az majd alacsony hőfokú (pl. 40 fokos) vízzel történik, ha nagyon, akkor pedig melegebb (pl. 60 fokos) vízzel.
A kapcsolódó kódok pedig a szokott helyen, a github-on.
Amikor nekiálltam az építsünk okos házat projektnek, arra gondoltam, hogy az átlagos informatikai projektektől eltérően ez egy egyszerű dolog lesz, buktatók és problémák nélkül, pár hét alatt véget is ér. Annyira bíztam ebben, hogy még repository-t se csináltam, a forrásokat egyszerűen dropbox-on tartottam. Mostanra eljutottam oda, hogy az alapvetések már működnek, és újra se kell írni mindent (amíg nem jön az openhab v3). Igaz az ütemezéssel kicsit megcsúsztam, de hát mégicsak egy IT projektről van szó, ahol még azok sem mindig tudják mit akarnak, akik az általam használt komponenseket fejlesztik…
Jelenleg épp léptető motort programozok, 3D modelleket készítek nyomtatáshoz, integrálok, deriválok, szabadidőmben pedig egy megbízhatóbb MQTT kommunikációs protokol implementációján gondolkozom, az eszközök és az openhab között… Szóval az izgalmak még csak most kezdődnek (legalábbis annyi izgalom, amit az időm enged).
Újdonság viszont, hogy a projekt felkerült a github-ra, így az újabb dolgok már ott is megtalálhatók: https://github.com/voji/smarthome
Váratlanul ért a dolog… Feldugtam az ipad-et a számítógépemre, 5 év után először… Aztán sötét lett, és megjelent a “Connect to ITunes” felirat… Átfutott az agyamon a gondolat: Nem csináltam backupot. De hisz megfogadtam, hogy soha… Miért?! Hibáztam… Most bűnhődni fogok, és a pokolra jutok…
És meg is érkeztünk az IOS11-hez. Az első Ipad-emet pont azért adtam el, mert mindig szolgalelkűen feltelepítettem rá a frissítéseket. Amikor észrevettem a bajt, már nem lehetett visszalépni az IOS 6-ra. Cserébe minden a többszörösére lassult, még a web böngésző is, amire a tabletet elsősorban használtam. Azt mondtam, rendben, ha így játszunk, játszunk. Vettem egy új Ipad-et megjelenés után, IOS 8-al, és nem frissítettem. Egy jailbreak után elmagyaráztam neki, hogy itt nem lesz frissítés, és haverkodjon össze a libretro-val… Azt hittem idilli kapcsolatunknak már semmi nem vethet véget.
Aztán jött a google, és utána egyre több fejlesztő, aki azt mondta, hogy IOS 8 már nem támogatott platform… Így volt olyan app, amihez több frissítés nem jött, és olyan is, hogy már maga az app se (pl. google calendar). Elérkezettnek láttam az időt, elvégre egy IOS 8 – IOS 9 frissítésből mi baj lehet.
A baj az volt, hogy upgrade-t is csak Apple által aláírt IOS-re lehet mondani, az pedig már csak a 11-es. De amire ezt megtudtam, addigra már nem bootolt be többet az IOS 8, én pedig nem készítettem backupot… Így hát beáltam a sorba, elmorzsoltam egy könnycseppet a libRetro után, és rányomtam a frissítés gombra.
Disclaimer: a frissítés teljes frissítés volt, semmilyen beállítást nem vettem át az ICloud-ból. Az itt leírt hibák az általuk kiadott stock operációs rendszeren jelentkeztek…
Nézzük mit is sikerült az Apple-nek fejlesztenie az elmúlt 5 évben:
És ezek a hibák azok, amit saját magam találtam 1 hét használat után… Az interneten rá se merek keresni, hogy mit találtak mások. Összességében az Apple elérte, hogy pár óra leforgása alatt pont annyira utáljam, mint amennyire utáltam az iPad megjelenése előtt. Nem korrekt kifizetett alkalmazásokat nem támogatni, megszüntetni a régi IOS-ek aláírását, hogy nem telepíthetek olyan nyílt forráskódú szoftvert egy általam megvásárolt eszközre amit akarok (pl. retroArch). Nálam itt ért véget az Apple story. Ha lenne Apple részvényem, ez lenne az a pont, amikor eladnám, és a befolyt összegből vennék egy Microsoft Surface Pro-t.
Eddig is zavart, hogy olyan funkciókat amik egyszerűen, és jól megoldhatók lokális alkalmazásokkal, iszonyú munka és erőforrás árán web alapú “alkalmazássá” alakítanak. Tegnap végül elegem lett, és úgy döntöttem, hogy a napi munkavégzés során kerülöm a web alapú alkalmazásokat. Lassúak, iszonyú erőforrást használnak, és a helyzet az idő múlásával (az alkalmazások komplexitásának növekedésével) egyre rosszabb, amit jól szemléltet az alábbi ábra:
330 mb csak a Google Inbox, hozzá jön még a böngésző 400 mb-ja, így 700 mega memória szükséges ahhoz, hogy el tudjam olvasni a leveleim (egy részét). Tegyük hozzá, hogy egy levél megnyitása másodpercekig tart, és néha már a sima szövegbevitel is akadozik…
A fentiek ellenére van létjogosultsága, hogy megnézzem a leveleimet egy böngészőben, de nem akkor, ha az elkövetkező 8 órában arra készülök, hogy levelekkel dolgozzak.
Az elmúlt időben annyira megszerette mindenki ezeket a csodálatos webalkalmazásokat, hogy már nem is nagyon gondolkoznak másban. Nekem volt pár ötletem, de mielőtt teszteltem volna, kerestem cikkeket, hogy miért jobb az asztali (nem a web alapú) Microsoft Office Outlook-ot használni, mint a gmail-t böngészőben, de mindenki csak a web-es platformokat hasonlítgatta, fel sem merült bennük egy ilyen jellegű összehasonlítás.
Gondoltam amiről nem írnak az emberek, az csak jó lehet, így belevágtam a dologba. Az átállás első (és legegyszerűbb) lépése a levelezés kiváltása. Szerencsére ott az IMAP protokoll, engedélyezni kell, és meg is történik a csoda. Persze erre azért várni kell, mert a levelek letöltése / indexelése nem egy gyors dolog. Ezen sokat segíthet, ha bizonyos könyvtárakat (pl. Important items) nem is szinkronizálunk, míg más könyvtárakban (Spam) csak a levelek fejléceit töltjük le. Az eredmény magáért beszél, az Outlook 150 Mb memóriát használ, mindkét levelezésemmel, szemben a webmail 1.1 Gb-os memória használatával. UI reszponzivitás terén pedig nem is kérdés, hogy az outlook jobb (letöltött levelekből dolgozik, native ui, stb.).
A gmail webapp elhagyásával viszont megszűnik még pár dolog, mint pl. a hangouts, amit ki lehet váltani honlappal (hangouts.google.com) és elbúcsúzhatunk újabb 200 mb memóriától, esetleg a yakyak alkalmazással ami elektron alapú (így csak 180mb memóriát használ, de cserébe nem kezel több accountot…), és a jó öreg pidgin-el. Ez utóbbi előnye, hogy a facebook chat-et is bele lehet kötni, szóval az összes IM üzenet egy helyen kezelhető. Hangouts és facebook használatához szükséges az alábbi két extra plugin, de utána gond nélkül működik minden:
Ezek után mindhárom IM kliens együttesen fogyaszt 38 Mb memóriát, viszont ennyiből gyorsabban és jobban működnek…
A google drive-ra szerencsére már régóta van megoldás, a Drive File System, ez nem újdonság, eddig is ezt használtam, mert a web alapú fájlkezelés pokol.
Elvesztek még a már ismert contactok, de azokat be lehet szinkronizálni a GO Contacts Sync Mod-al. Mivel nem gyakran változnak, ezért ki is kapcsoltam az automatikus szinkronizálást.
Egyedül a naptár kezelésére nem találtam korrekt offline megoldást, abból maradt az online verzió, és a -180 Mb memória…
Alternatívaként még felmerülhet pár dolog az outlook helyett, ilyen pl. az eM Client ami kezeli a google contact-okat és a calendar-t is alapból, viszont az Outlookkal ellentétben nem tölti le a leveleket, így a használat során várni kell a levelek megnyitására. Ezzel meg lehet spórolni a memória használatot és a gui is gyorsabb mint a web alapú negoldás, de összességében a leveleket előre letöltő kliensek gyorsabbak. Nyílt forrású alternatíva még a Thunderbird, amit régebben használtam (pont az outlook után) de már nem volt energiám újra előszedni.
Előző héten eltűnt az internet, és a magam visszafogott módján próbáltam jelezni a szolgáltatónak, hogy nem annyira jófejség családokat a digitális őskorba száműzni…
Sajnos nem jártam sikerrel (legalábbis 3 nap múlva még mindig nem volt net), ezért úgy gondoltam ideje szakember segítségét kérni. Baráti segítséggel (köszi Attis!) megtaláltam az ide vonatkozó hanganyagot. Mivel hosszas gyakorlás után sem tudtam megközelíteni a mester teljesítményét, ezért inkább megvágtam az anyagot, későbbi felhasználásra.
Szóval ha elmenne az internet, akkor hangfal felhangosít, háttérzaj leszáll, és indulhat is a panaszbejelentési folyamat, az alábbi mankókkal.
Nem akarsz elmenni a picsaba
Szar az adsl te meg ott vakarozol
Mit csinalsz ott
Nem lenne szar az adsl ha dolgoznal
Picsaba bazd meg
Szar az adsl erted es vakaroztok ottan
Mit kepzeltek
Vakarozol es szar az adsl nem tudunk netezni
Itt van az egesz csaladom es nem tud senki netezni
Nem megy erted, javitsd meg bazdmeg
Itt van ez a szar, ra van irva, hogy ize
Mondom, hogy vakarozol bazdmeg
Mozgas, nem erek ra bazdmeg
Meg ma bazdmeg, mintha elnel
Nem sertegetlek, de faszom tele, hogy nem megy az internet
Ha épp megy az internet, és csak amolyan munka utáni felüdülésként szeretnéd magadba szívni a hatékony panaszbejelentés rejtelmeit, akkor rakd be alá Ellen Allien – Jack My Ass c. számát, és nyomogasd random a play gombot… 🙂
Ui: amire elkészültem a wav-okkal, addigra érkeztek meg a levelek a szerveremtől, hogy dolgokat nem tudott elintézni, de most már minden ok… Így élesben nem tudtam tesztelni a dolgot, de ami késik, nem múlik 🙂
Az utóbbi időben a processzorok órajele mellett azok energia gazdálkodási funkcióit is jelentősen fejlesztették, ami elég hasznos egy laptop esetén, és nem mindig hasznos pl. valós idejű használat során egy asztali gépben.
Akit nem érdekel a fogyasztás, ellenben konstans performanciát szeretne elérni, érdemes lehet módosítani az alapértelmezett energiagazdálkodási beállításokat (power options).
Ehhez egy jó kiindulási alapot nyújthat az alábbi cikk:
http://www.dozty.com/how-to-unlock-the-hidden-features-of-processor-power-management/
Az újabb Windows verziók kapcsán – kivéve Windows 10 – a Microsoft kiemelt figyelmet fordított az operációs rendszer teljesítménye. Az ez irányú törekvések emlékét őrzik az egyre jobb performancia elemző eszközök, mint pl. a Task Manager (és az onnan elérhető Resource Monitor). Bár ezek továbbra sem váltják ki a jó öreg Process Explorer, Process Monitor-t, de az esetek egy részében a problémák már detektálhatók natív windows-os eszközökkel (is).
A szuper optimalizált windows-om a napokban ismét lehetőséget biztosított, hogy foglalkozzak vele kicsit, mert login előtt megállt, és várt vagy 20 másodpercet, ezután dobott a login képernyőre. Mivel itt még boot fázisról beszélünk, sajnos a fenti eszközök egyike sem használható. Első körben megnéztem az event log-ot, hátha találok benne valami érdekeset (ahogy a mondás tartja, aki keres az talál), de ennek a várakozáshoz sajnos nem volt köze.
Egyéb okokból már telepítve volt a gépen a Windows Assessment and Deployment Kit (Windows ADK) Windows Performance Analyzer komponense, ami lehetőséget biztosít trace-k készítésére, azok elemzésére, akár boot idő alatt is.
A használatához rá kell venni a windows-t, hogy trace fájlt generáljon, melyből majd kideríthetjük, hogy mi is történik a vizsgált időszakban. Régen ehhez pár száz karakterből álló parancssort kellett készíteni (xbootmgr…), de a Microsoftnál is sejthették, hogy ez ebben a formában nem valami jó, és egy szorgalmas fejlesztőnek hála ma már ezt konfigurálhatjuk grafikus felületen is (na jó a felület képességeit nem vitték túlzásba, de hát ki a kicsit nem becsüli…).
wprui.exe
Az ily módon megkeletkezett fájlt (pl.: boot_1.etl) a Windows Performance Analyzer-rel tudjuk alaposabban megvizsgálni. Mivel az én problémám a boot alatt jelentkezett, de még login előtt, az első nézet amit bekapcsoltam a Boot Phases volt. Itt már látszott, hogy a bejelentkezés előtt a Winlogon init 31 másodpercig tartott, ami gombócból is sok, nem hogy boot időből…
A fenti nézethez hozzádobtam még a Processes nézetet, hogy látszódjon milyen alkalmazások indultak el ezen idő alatt.
A processeket vizsgálgatva feltűnt egy alkalmazás ami a login inittel indult, és 29.9 másodpercig futott… Ez az alkalmazás pedig nem volt más, mint az OriginWebHelperService.exe…
Ezután eszembe jutott, hogy nemrég elindítottam az Origin-t, és frissítette magát… A process egyébként service-ként települt, a frissítés rakta fel/kapcsolta be, ott kellett kikapcsolni, és a probléma megszűnt… Ezúton is köszönöm az EA-nak a fejtörőt, szórakoztatóbb volt, mint a legtöbb mostani játékuk 😉
Táblák kezelése kapcsán előfordul néha, hogy bizonyos dupla előfordulásokat szeretnénk megjelölni/kitörölni. Ezt a Google spreadsheet-ek esetén script segítségével tehetjük meg.
Az alábbi script pirossal jelöli azon sor előfordulásokat, ami a táblázatban már egyszer szerepelt:
function markDuplicates() {
var sheet = SpreadsheetApp.getActiveSheet();
var range = sheet.getDataRange();
var newData = new Array();
for(var i = range.getRow(); i < range.getLastRow(); i++){
var row = range.offset(i, 0, 1);
var rowData = row.getValues();
for(j in newData){
if(rowData.join() == newData[j].join()){
row.setBackgroundRGB(255, 0, 0);
}
}
newData.push(rowData);
}
}
A kód készítése során az alábbi források segítettek:
Tutorial: Removing Duplicate Rows in a Spreadsheet
Google Spreadsheet: Script to Change Row Color when a cell changes text