Egy korábbi bejegyzésemben már foglalkoztam BlackBerryvel, azaz akkori nevén még Research In Motion-nel egy PlayBook-os promóció kapcsán. Időközben folytatódott a történet és kollégákkal közösen sikerült szerezni pár BlackBerry Dev Alpha B telefont. Erről nagyon tömören annyit érdemes tudni, hogy a BlackBerry Z10-esének a fejlesztői változata (az eltérő külső ne tévesszen meg senkit, a Dev Alpha B és a Z10 közt csak egy a "Dev Alpha B" feliratot tartalmazó extra keret elem a különbség; igaz, ettől némileg "téglásodik" az eszköz).

Nemrég sikerült befejezni a "nagymama project" névre hallgató teljes adatbázis ellenőrzést a 'Legyen Ön is Milliomos!' Facebook játékban.

Az ellenőrzés elsődleges célja az volt, hogy az általános iskola végén és a középiskola elején született adatbázisban az egyes kérdésekhez tartozó nehézségi szintek megközelítőleg helyes értékekre kerüljenek, illetve a feltűnően rossz kérdések is javítva, törölve legyenek.

Ezen törekvéseim a mai nappal teljesültek a már említett "nagymama project" keretében, melynek túlnyomó részét nagymamám végezte szabadidejében, egy az öcsém által kifejezetten erre a célra készített adminisztrációs felület segítségével.

Néha elgondolkozok rajta, hogy konkrétan, éves szinten mennyi időt enged meg például a legtöbb webhoszting szolgáltatónál megadott 99.9%-os rendelkezésre állás. Ilyenkor általában előveszem Google barátunkat, vagy a Wolframalpha-t és szépen kiszámoltatom valamelyikkel, mert hát nem egy nagy cucc ugyebár. Aztán ma ezzel ellentétben ha lehet ilyet, akkor a még lustábbik utat választottam és egész egyszerűen rágugliztam a rendelkezésre állás kifejezésre, amire pedig ezt találtam:

Availability %	Downtime per year	Downtime per month*	Downtime per week
90% ("one nine")	36.5 days	72 hours	16.8 hours
95%	18.25 days	36 hours	8.4 hours
97%	10.96 days	21.6 hours	5.04 hours
98%	7.30 days	14.4 hours	3.36 hours
99% ("two nines")	3.65 days	7.20 hours	1.68 hours
99.5%	1.83 days	3.60 hours	50.4 minutes
99.8%	17.52 hours	86.23 minutes	20.16 minutes
99.9% ("three nines")	8.76 hours	43.2 minutes	10.1 minutes
99.95%	4.38 hours	21.56 minutes	5.04 minutes
99.99% ("four nines")	52.56 minutes	4.32 minutes	1.01 minutes
99.999% ("five nines")	5.26 minutes	25.9 seconds	6.05 seconds
99.9999% ("six nines")	31.5 seconds	2.59 seconds	0.605 seconds

* For monthly calculations, a 30-day month is used

Elkezdtünk családilag teszt felhasználóneveket kitalálni a szakdolgozatomhoz:

• Teszt Elek
• Gipsz Jakab
• Mezei Virág
• Vincs Eszter
• Disz Nóra
• Eszet Lenke

Egyik barátom felvetésére készítettem egy rss feedet a bloghoz, így mától az itt lévő bejegyzések azon keresztül is követhetővé váltak.

A feed elkészítéséhez a Views Drupal modult és ezt a leírást használtam. Ezeknek köszönhetően pár perc alatt bármikor összerakható egy kellően testraszabható rss feed.

Szerettem volna letiltani egy VMware-es guest OS-ben az óra szinkronizálását, viszont mivel ezt a VMware Tools-ból Windows alatt hiába tettem, mert minden újraindításnál fene mód újra szinkronizálta az órát, ezért keresgéltem egy kicsit és a következőt találtam:

1. Nyissuk meg az érintett virtuális gép .vmw fájlját
2. Adjuk hozzá/modosístuk a következő értékett
   time.synchronize.tools.startup = "FALSE"
3. Ha a guest OS is szeretne internetről szinkronizálni, akkor azt még érdemes lehet letiltani vagy megszakítani az internet kapcsolatot a virtuális gép konzolján ("kábel kihúzás")

Már egy ideje foglalkoztat a gondolat, hogy a home.halacs.hu szerveremen lévő email szolgáltatáshoz érdmes lenne beállítani egy tartalék levelező szervert, ami az elsődleges gép elérhetetlensége esetén is tudná fogadni és átmenetileg tárolni a leveleket.

Figyelembe véve a kiszolgáló minimális e-mail forgalmát (szűk baráti kör), a dolog gyakorlati jelentőssége nem túl nagy (különösen az smtp-k "próbálkozós" működését ismerve), mégis a megvalósítás mellett döntöttem. Talán elsősorban kíváncsiságból.

A backup mail exchanger végül egy Ubuntu Serveren futó Postfix e-mail kiszolgáló alklamazás lett.

Az utóbbi napokban/hetekben jelentős forgalomnövekedés tapasztalható a Legyen Ön is Milliomos! Facebook játékban. Az eddigiekhez képes egy-két nagyságrendes napi játékosszám ugrás jelentkezett karácsony napjától kezdődően.

Ennek oka vélhetően egy elírás javítása, ami miatt a játék által a játékosok üzenőfalára posztolt üzenetek rossz webcímre mutattak. A hibás linket kijavítottam, az már a játék Facebook profil oldalára mutat.

Az utóbbi időben egyre növekvő játékos számnak köszönhetően egyre többször fordult elő a játékosok által is érzékelhető hiba, mely vélhetően a webtárhely szolgáltatónak felróható okokból jelentkezik.

Mivel a hibajelzésre a tárhely szolgáltatótól az elvárható időn belül nem érkezett válasz, elérkezettnek láttam az időt a játék felhő alapú kiszolgálóra történő költöztetésére, melyen nem csak a nagyobb rendelkezésre állás, de a kiszolgáló teljes konfigurálhatósága is előnyként jelentkezik. Utóbbinak a jövőbeni tervek kapcsán lehet még komolyabb jelentőssége.

A Legyen Ön is Milliomos! Facebook játék publikálása óta fájó pont volt, hogy az "éles" verziónak tegnapig tárhelyet biztosító cég bizonyos dolgokat éjjelente önkényesen módosít az adatbázisban. Bár ezt feltehetően optimalizációs céllal, automatizáltan teszi, mégis elég kellemetlenül érintett, mikor észrevettem, hogy a MySQL nézeteim éjjelente törlésre kerülnek, illetve hogy az adatbázis táblákban is új indexek képződnek, melyeket aztán hiába hoztam létre újra, vagy töröltem a létrejövőket, minden este (vélhetően a biztonsági mentések készítése körül, hajnal 3 órakor) újra és újra törlődtek illetve létrejöttek, ráadásul a cégnek ezügyben küldött e-mailekre sem kaptam soha érdemi választ.