Blog by Pál "voji" Vojácsek
A mobil alkalmazásfejlesztés terén sokan próbálkoztak már mindenféle cross platform fordítóval, most úgy tűnik, hogy egy igazán nagy név is beszáll a játékba:
https://software.intel.com/en-us/blogs/2015/07/30/multi-os-engine-of-intel-inde-technical-overview
A 10 számú windows esetében a fejlesztők szó szerint értelmezték az automatikus frissítések funkciót. Ugyanis ezen windows verzió óta a frissítések letöltése tényleg felhasználói interakció nélkül (automatikusan) történik. Ezzel egy kábelen lógó asztali gép esetén nincs is baj, de elég kellemetlen meglepetés érheti az embert, amikor a windows öntudatára ébred, és a legfontosabb feladatának a frissítések letöltését tekinti. Mondjuk mobilneten, egy megbeszélés közepén, amikor nagyon kellene egy dokumentum, ami a felhőben van…
A Microsoft által javasolt pol-korrekt megoldás az lenne, hogy minden ilyen jellegű wifi kapcsolat esetén állítsuk be, hogy Metered connection-ről van szó, de nekem semmi kedvem ezt átvezetni az összes elmentett wifi kapcsolatomon, valamint minden új kapcsolatkor, kapcsolódás után, külön. Amúgy sem szerencsés, ha az operációs rendszer akkor töltöget amikor csak kedve támad. Én úgy gondolom, hogy azt csak a felhasználó tudja, mikor nem zavarja, hogy a windows berántja a rendelkezésre álló sávszélességet.
Az automatikus frissítés letöltés kikapcsolására van mód, és jó leírás is:
Sokat hozzátenni nem is tudok, talán csak annyit, hogy nekem a 2 érték nem működött, az 5 viszont igen, így érdemes azzal próbálkozni elsőre.
Egyre több program tárolja az adatokat XML formátumban, ami kezelése nem egyszerű a hagyományos parancssori eszközökkel (grep, sed, és társai). Az XML formátum kezelésére viszont léteznek már újabb eszközök, mint például az XmlStarlet. Ez gyakorlatilag egy parancssori XML szerkesztő tool, melynek segítségével könnyedén nyerhetünk ki, vagy adhatunk, módosíthatunk adatokat az XML formátumú fájlokban.
A használata során nem árt képben lenni az XPATH fogalmával, és formátumával. Ehhez jó kiindulási alap lehet az W3Schools leírása. A munka során jó szolgálatot tehetnek még az online XPATH teszterek, generátorok.
Egy sok xml-t módosító (alap) script valahogy így néz ki a gyakorlatban:
#!/bin/sh
WORKSPACE=/cygdrive/t/work/
for x in `ls -d ${WORKSPACE}/*/`;
do
PROJ_FILE=${x}build.xml
if [ -f ${PROJ_FILE} ]
then
echo Processing build file: ${PROJ_FILE}
xmlstarlet ed -O -P -a "/project" -t attr -n default -v "rebuild_release" ${PROJ_FILE}
fi
done
A futtatás során a megadott könyvtár alkönyvtáraiban található build.xml fájlok tartalma az alábbi képpen módosul:
Eredeti tartalom:
<?xml version="1.0" encoding="UTF-8"?> <project name="ac"> <import file="../build/common.xml"/>
Tartalom a módosítás után:
<?xml version="1.0" encoding="UTF-8"?> <project name="ac" default="rebuild_release"> <import file="../build/common.xml"/>
A példa nem vizsgálja, hogy az XML tartalmaz e már default attribútumot, de ezt igény esetén egy újabb xmlstarlet query-vel és egy if-el könnyedén ellenőrizhetnénk. Jelen működés alapján, ha kétszer futtatnák le a fenti kódot, akkor az xml-ekben 2x kerülne beszúrásra a default tag.
A nagy windows 10 upgrade után többen meglepődve tapasztalhatják, hogy nem tudnak Recovery drive-ot létrehozni a megszokott módon. A fórumokban elég nagy a tanácstalanság, de a probléma, nem új keletű, már windows 8.1-ben is jelen volt. Az okokat és a lehetséges megoldást szépen összefoglalja a neosmart csapat wiki oldala: https://neosmart.net/wiki/we-cant-create-a-recovery-drive-on-this-pc/
A lényeg: recovery partíció hiányában (ami upgrade esetén nem jön létre) kénytelenek vagyunk mi megadni egy helyet (a reagentc segítségével), ahol a windows telepítő elérhető.
Aki viszont nem rendelkezik windows 10 telepítővel, vagy egyszerűen csak egy gyorsabb megoldást szeretne, igénybe veheti az EasyRe alkalmazást, ami windows 10 alá ingyenesen letölthető: https://neosmart.net/EasyRE/
A reviewboard egy egyszerű, de használható eszköz (ha az ember készít hozzá egy jó review allocator programot, de erről majd máskor). A használat során arra törekedtünk, hogy egy commitot több ember is megnézzen, ezt viszont a reviewboard valamiért nem annyira támogatja.
Mint a mellékelt képen is látszik, a reviewboard a ship-it-et egy zöld pipával jelöli. Ha valaki azt mondja a review-re, hogy Ship it, akkor a pipa megjelenik. Ellenben ha több reviewer van egy ticketen, ez nem a legszerencsésebb dolog.
Nekünk az elvárt működés valami ilyesmi lett volna:
Ehhez az alábbi módosításra van szükség:
Első lépésben meg kell keresni menni a reviewboard egg csomagját, ahol a forrás fájlok is (.py) találhatóak. Ez operációs rendszer, python verzió függő, de az alábbi helyen érdemes keresni:
/usr/local/lib/python2.7/dist-packages/ReviewBoard-2.0.18-py2.7.egg
Az oszlopok definíciója a reviewboard\datagrids\columns.py fájlban van. A ShipIt column-ot előállító kódot meglepő módon ShipItColumn-nak hívják. A kapcsolódó forráskód így néz ki:
class ShipItColumn(Column):
"""Shows the "Ship It" count for a review request."""
def __init__(self, *args, **kwargs):
super(ShipItColumn, self).__init__(
image_class='rb-icon rb-icon-shipit',
image_alt=_('Ship It!'),
detailed_label = _('Ship It!'),
db_field='shipit_count',
sortable=True,
shrink=True,
*args, **kwargs)
def render_data(self, state, review_request):
if review_request.issue_open_count > 0:
return ('<span class="issue-count">'
' <span class="issue-icon">!</span> %s'
'</span>'
% review_request.issue_open_count)
elif review_request.shipit_count > 0:
return '<span class="shipit-count">' \
'
<div class="rb-icon rb-icon-shipit-checkmark"' \ ' title="%s"></div>
%s' \
'</span>' % \
(self.image_alt, review_request.shipit_count)
else:
return ''
A minket érdeklő rész, leginkább az if második fele: review_request.shipit_count > 0:
Itt kezelik azt a részt, ha a ticketen 0-nál több ship it van… Ezt jobb lenne korrektül kezelni, az alábbi módon:
elif review_request.shipit_count > 0:
peoplecount=review_request.target_people.count()
shipicount=review_request.shipit_count
additionalclasstext=''
if shipicount>=peoplecount:
additionalclasstext=' rb-icon-shipit-checkmark'
return '<span class="shipit-count">' \
'
<div class="rb-icon %s"' \ ' title="%s"></div>
%s/%d' \
'</span>' % \
(additionalclasstext, self.image_alt, shipicount, peoplecount)
A fájl szerkesztésénél figyelni kell a szóközökre, ugyanis a python fájlok nagyon nem szeretik a tab-okat, és a szóközök nem csak a formázásra szolgálnak…
A módosítások után, amennyiben van lefordított columns.py fájl (columns.pyc), akkor azt töröljük. Ha valaki szeretné, lefordíthatja újra az alábbi script-el:
#!/usr/bin/env python
import py_compile
py_compile.compile("columns.py")
Aki gyakran használ wifi hálózatokat, azzal rendszerint megesik, hogy gyorsan felcsatlakozik valahova, és aztán a jelszó örökre a windows bugyraiban hánykolódik az idők végezetéig. És amikor laptopot/windowst/esetleg másik eszközt szeretnénk használni, jön a kínos kérdés, hogy Te mi is volt a WIFI jelszó? Én rászoktam arra, hogy minden ilyen jellegű megadott jelszót először keepass-ba írok, majd aztán a wifi csatlakozáshoz, de ez is idő, és mint tudjuk abból nem mindig van sok.
Hamarosan remélem az egész jelszavazásnak semmi értelme nem lesz, mert egyszerűen mindenhol lesz net… De addig maradnak a jelszavak, és a hozzá kapcsolódó macera.
Ha már elmentettünk egy wifi hálózatot, sokat nem tudunk a windows-ba kezdeni vele (legalábbis a jelszavát biztos nem tudjuk megnézni), csak ha csatlakoztunk már hozzá. Ha viszont csak egy listát szeretnénk látni, jelszavakkal, érdemes megnézni a Wifi8 nevű ingyenes programot.
http://www.thewindowsclub.com/wifi-profile-manager-windows-8
Annyira új UI-t kapott a program, hogy csak na, látszik, hogy windows megszállottak írták. Bár azt az egyszerű esetet nem kezeli le, hogy ha meg van nyitva egy kapcsolat tulajdonsága, akkor egy új kapcsolat tulajdonság megnyitása során a jelszó is frissüljön (az előző kapcsolatét mutatja tovább), de ezt a részét nem nagyon érdemes használni, ki lehet exportálni a kapcsolatok listáját jelszavakkal xml-be, és ez a legnagyobb királyság, ami elfelejtett wifi jelszavakkal történhet.
Az online játékokban általában a játékoson múlik mennyire jó, a teljesítményét – mint a technikai sportoknál általában – befolyásolhatja, hogy milyen beállítások mentén éri el az adott eredményeket. Nem állítom, hogy a profi beállítások használatával valaki jobb/rosszabb játékos lesz, de a mögöttük lévő gondolatok lehetnek érdekesek.
Azt hihetnénk, hogy a top játékosok kihasználják az egerek, billentyűzetek (és más egyéb fő támogatók által kínált hardverek) képességeit, de a színfalak mögé tekintve, érdekes dolgokat tapasztalhatunk.
Az egér, billentyűzet, terén minden profi ligára igaz az egy gomb – egy akció elv. Tehát ha egy gomb lenyomására több dolog is történik a játékban, akkor az csalás. Ezáltal a makrók, és minden extra funkció amit ezek az eszközök nyújtanak alapból nem használhatóak.
Ha már az egereknél tartunk, szintén érdekes, hogy a legtöbb profi játékos 400dpi körül használja az egeret, miközben a gamer egerek dpi képessége az egekbe szökött. Pedig ha belegondolunk, a túl érzékeny egérrel több gond is van. Például jobban felszedi a hibákat, ami az egérpadon jelentkezik, az input nem interpolál…
A felbontás kapcsán pedig gyakran feltűnik a 4:3-as képarány, ami igen csak nem standard a mai monitoroknál (az 1024×768 felbontásról már nem is beszélve).
A 16:9 felbontásokkal szemben az a kifogása a legtöbb játékosnak, hogy a szemnek mozognia kell, ha a teljes képet szeretné látni, míg 4:3-ban jobban tud az ember fókuszálni, nem vonja el a figyelmét az, ami a képernyő szélén történik (pl. minimap). Az alacsony felbontás ráadásul garantálja, hogy bármivel játszunk, a elég nagy FPS-t érjük el. A 4:3-as felbontáshoz kapcsolódik, hogy a beállítást, úgynevezett “black bar” módban használják, tehát a kép nem scale-ződik ki a monitorra, hanem a két oldalon két fekete csík van.
És akkor mire is figyeljünk gamer eszközök vásárláskor ennek fényében:
Források:
http://www.tobyscs.com/optimal-mouse-settings-csgo/
https://docs.google.com/spreadsheets/d/12PSHqb8Vwg8rSCOkGjbbsj8iBsm8p52jOLffDc88iy8/edit#gid=0
http://team-dignitas.net/articles/blogs/CSGO/6033/Set-Up-CSGO-like-the-Team-Dignitas-Pros
Réges rég (egy messzi messzi galaxisban…) futottam pár kört, word dokumentumok pdf-be történő konvertálásával. A napokban megint felmerült a probléma, így gondoltam megosztom a listát, ilyen esetben mire kell figyelni.
1. Ha minőségi pdf-et szeretnénk készíteni, akkor Adobe Acrobat.
2. A beállítások fontosak:
http://wordtopdfimage.blogspot.hu/2012/02/preserve-image-quality-when-saving-from.html
A windows 8 is tud nagy file cache-el dolgozni, csak alapból nem szokott. Viszont ha sok memória van a gépünkbe, és sok fájlal dolgozunk (pl. a szoftvert fejlesztünk), akkor érdemes lehet megnövelt file cache-t használni windows alatt.
A file cache policy paraméterezhető, csak a paraméterezés picit el van rejtve. Kezdetnek egy commant prompt-ot kell szereznünk administratorként, ott adjuk ki az alábbi parancsot, amivel megtuthatjuk a jelenlegi beállítását a file cache-nek:
fsutil behavior query MemoryUsage
Az itt visszakapott szám az alábbit jelenti:
Nekünk a megnövelt cache policy kellene, ezt az alábbi utasítással tudjuk beállítani:
fsutil behavior set memoryusage 2
A módosítás után szükséges egy restart.
Forrás: http://www.ghacks.net/2010/07/08/increase-the-filesystem-memory-cache-size-in-windows-7/
Az utóbbi időben a hálózati helyekről jelentősen lassult az Excel fájlok megnyitása. Ennek az oka, egy új, a windows update által letöltött, és telepített kiegészítő, melynek a neve:
Microsoft Office File Validation Add-In
Ha továbbra is szeretnénk excel fájlainkat gyorsan, és fájdalommentesen megnyitni a hálózati helyekről, akkor távolítsuk el ezt a kiegészítőt a gépünkről (Control Panel, Add/Remove Programs).