AdBlock Plus on android

Az AdBlock Plus böngésző bővítmény minden telepítés során az elsők között van nálam, a mobil alkalmazásokért pedig inkább fizetek, semmint reklámokat nézzek. Viszont amikor már iOS-en és Androidon is fizetnem kellene a reklámok letiltásáért egyazon alkalmazáson belül, akkor elszomorodok…

Egy ilyen elszomorodásom alkalmával gondoltam rákeresek, hogy van e megoldás androidon belül arra, hogy kikapcsoljam a kéretlen reklámokat. Meglepődtem, amikor az AdBlock Plus for Android volt az első találat. Maga a koncepció zseniális, a mobil verzió ugyanis egy lokális proxy, ami a reklámokat szolgáltató szerverek felé egyszerűen nem engedi át a forgalmat. Így gyakorlatilag minden böngésző, és alkalmazás alatt működik.

Telepítés után az egyetlen dolog, hogy a rendszer életre kelljen az az internet elérésre használt kapcsolatok módosítása, hogy a forgalmat az AdBlock Plus által.

Ezt úgy tudjuk megtenni, ha az aktuális wifi kapcsolatra hosszan klikkelünk, majd a felugró menüben kiválasztjuk a modify connection opciót, és ott megadjuk a proxy szervert (alapból a címe localhost és a port 2020).

A mobil adatkapcsolat esetén is hasonlóan kell eljárnunk, csak ott Settings -> More… -> Mobile networks -> Access Point Names -> (alapértelmezett AP ami ki van pipálva) -> Proxy és Port beállítások

Selenium headless test

A selenium egy zseniális eszköz, én személy szerint nem csak tesztelésre, hanem folyamat automatizálásra is egyre többet használom. Néha egyszerűen x nélkül szeretném használni, hogy csinálja meg amit szeretnék, a többi dolog nem is érdekel.

Ehhez az alábbi dolgok szükségesek:

  • firefox (apt-get install firefox)
  • java (apt-get install default-jre)
  • selenium, és selenium RC (lásd később)
  • egy két csomag, hogy fusson a firefox x nélkül (apt-get -y install xvfb x11-xkb-utils xfonts-100dpi xfonts-75dpi xfonts-scalable xfonts-cyrillic libstdc++5 xserver-xorg-core xauth dbus-x11)

Első lépésként bármilyen gépen el kell készíteni magát a teszt esetet. Ehhez a firefox alá fel kell telepíteni a selenium plugint, amiben a record-al felvehetjük amit csinálunk, majd menthetjük. Fontos, hogy nekünk nem csak egy teszt esetre (test case), hanem egy test suite-ra is szükségünk lesz. Tehát először mentsük a tesztesetet (File – Save Test Case) majd a hozzá tartozó Test Sutie-ot is (File – Save Test Suite).

Ezek után irány a linux, ahol az alábbi script-el tudjuk elrúgni a tesztet:

#!/bin/sh
Xvfb -fp /usr/share/fonts/X11/misc/ :22 -screen 0 1024x768x16 2>&1 &
export DISPLAY=:22
java -jar selenium-server-standalone-2.42.2.jar -htmlSuite "*firefox" "http://192.168.2.1" "rrestart_suite.html" "results.html"

A fenti példában:

  • “http://192.168.2.1” – az oldal címe, amint a tesztesetet le fogja futtatni
  • “rrestart_suite.html” – a test suite neve
  • “results.html” – ebbe a fájlba kerülnek naplózásra futási eredmények

Egyébként a seleniumot meg lehet hajtani java programból is, ami egy sokkal érdekesebb téma(ez által lehet pl. excel adatforrás alapú tömeges tesztelést végezni). Ha lesz időm, talán arról is készül majd egy rövid cikk.

OSX telepítés virtualbox alá

Ha az ember olyan programot ír, ami több platformon is működik, akkor jó eséllyel hibákat is fog kapni ezen platformokról. Kedvenc hobbi projektem miatt égetően szükségem lett egy osx-re, hogy egy két dolgot meg tudjak nézni. Már egy ideje virtualbox-ban használom a linuxot, gondoltam próbát teszek az OS X-el is, hátha.

Találtam egy cikket a lifehacker-en, ami alapján úgy tűnt, hogy van esély működésre bírni egy OS X-et a virtuális gépben… Ezen felbuzdulva le is töltöttem egy jónak tűnő OS X telepítőt, aminek a leírásában szerepelt a hacked, meg a virtualbox szó… 🙂

Első próbálkozásom hatalmas kernel pánikok, fagyások jellemezték… Itt kétségbeestem, és próbálkoztam mindenfélével, pl. az iBoot-al amivel el is indult a telepítő, hogy a végén jól szétfagyjon.

Aztán ráakadtam egy blog bejegyzésre, ami alapján úgy tűnt, hogy életre lehet kelteni a mac-at iBoot nélkül is, csak el kell hitetni az OS X-el, hogy amin fut, az egy mac. Ezt azért egy virtuális gépen nem is olyan nehéz megtenni, a 6. pont a lényeg.

<ExtraDataItem name="VBoxInternal2/SmcDeviceKey"
   value="ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc"/>
<ExtraDataItem name="VBoxInternal2/EfiGopMode" value="2"/>

Valamint még a <Firmware type=”EFI”/> átírtam  <Firmware type=”EFI64″/> -re.

Szerencsére a virtualbox konfigurációs fájl egy xml (csak a kiterjesztése .vbox), szóval nem is variáltam, beleírtam mindent, és láss csodát:

Screenshot 2014-05-26 13.53.41

 

 

Virtuális gépen picit lassúak az animációk, azokat érdemes kikapcsolni. Erre található ehhez egy jó leírás, ami alapján én az alábbi dolgokat kapcsoltam ki:

sudo defaults write NSGlobalDomain NSAutomaticWindowAnimationsEnabled -bool NO
sudo defaults write com.apple.dock expose-animation-duration -int 0
sudo defaults write com.apple.dock springboard-show-duration -int 0
sudo defaults write com.apple.dock springboard-hide-duration -int 0

És már csak a hálózati kapcsolat volt hátra… Ehhez a default gateway-t kellett megtudni:

route -n get default

ami a gazda gép ip címe a natolt hálózaton. Ehhez csatlakozva már elérhetőek a windows megosztások:

Finder -> Go -> Connect to server: smb://10.0.2.2

Öröm boldogság…

 

Ui: XCode 5-höz OS X 10.8.4 kell, nekem pedig 10.8.0 van, nem akartam szenvedni az upgrade-el, maradtam a 4.6.3 verziónál, de ez az apróság már csak a letöltés, és a telepítés után derül ki…

A a java fejlesztéshez szükséges eszközök terén is volt egy kis kavar, de ezen már meg se lepődök, viszont ennek kapcsán elég sokat futott az osx (böngészés, futtatás, konfigurálgatás), és eddig hibátlanul működik.

Rar fájlok kitömörítése

find . -name "*.rar" -exec unrar x '{}' \;

Let me explain what this does. 
"find ." - will find files within the current directory and any subdirectories
"-name "*.rar" - will only find *.rar files
"-exec " - will perform an external command on the results found by the "find" command. 
"unrar x" - is the command to extract the rar archives
"'{}'" - tells find to append the found result to the end of the exec'd command.
"\;" - signifies the end of the exec'd command.  forrás

Az a bizonyos í betű…

Eddig is hallottam a mechanikus billentyűzetekről, gondolkoztam is rajta, hogy veszek, mert a c64-en és régi ibm billentyűzeteken imádtam gépelni… A 444 cikk után végleg megszületett az elhatározás, szükségem van egy normális billentyűzetre…

Meg is rendeltem a nekem tetsző visszafogott dizájnú, Mx Brown mikrokapcsolókkal szerelt Keycool 108II billentyűzetemet ügyesen.

A billentyűzet igényes kidolgozású, a kábele könnyen cserélhető (usb – micro usb), adtak hozzá ps/2 átalakítót (billentyűzetnél az lehet jobb mint az usb), szóval elégedett voltam vele. Egyetlen problémát az jelentette, hogy a kiosztása angol. Nem is kérdés, hogy ezt egy picit szokni kell (pl. a ű helyett előszeretettel tudok entert ütni), de sokkal nagyobb problémát jelentett, hogy nem lehet vele í betűt írni. Erre a windowsban egyébként van megoldás alapból, mégpedig az altgr az alt-gr helyén lévő jobb alt és az i betű lenyomásával elő lehet csalogatni az Í betűt… Igen, a nagy Í betűt, ugyanis nekem bármit is csináltam csak ezt volt hajlandó írni…

A megoldást végül a régen sokat használt Autohotkey jelentette, az alábbi makróval:

!i::
Send í
return

Ennek eredménye

  • bal alt+i = í
  • jobb alt+i = Í

Azt hiszem rendelnem kellene egy normális billentyűzetet munkába is 🙂

A script 64-bit unicode exeben, letolthető innen: hunkey

Windows 8 remote desktop

Réges régen, még windows xp alatt a sikerült csinálni egy jó Remote Desktopot. Egyszerűen jobb volt mint az akkori alternatívák, vitt át hangot, képet, nyomtatókat, eszközöket, vágólapot, bejelentkezés nélkül is működött, stb. Szerettük.

Ezt a bravúrt windows 7-ben már nem sikerült megismételni, történt ugyanis, hogy még gigabites hálózaton is akadozik a Remote Desktop frissítése… Ezen Remote Desktop 8-ra történő frissítéssel, lehet segíteni, de az eredmény nem lesz tökéletes. Szerencsére többek között ezt a hibát is orvosolták a windows 8-ban, de nem a Microsoftról beszélnénk, ha a dolgok egyértelműek lennének (pl. a felhasználó név az felhasználó név, a típus az pedig típus).

Ha valaki viszont először próbál csatlakozni windows 8-as gépre, jó eséllyel a felhasználónév, és a jelszó megadása után az alábbi képernyővel fog találkozni:

snap082

 

A probléma, hogy arra már nem telt a kedves fejlesztőknek, hogy a felhasználói adatbevitelt rendesen megcsinálják, mert akkor 3 részből kellene, hogy álljon:

  • Felhasználó név
  • Jelszó
  • Felhasználó típusa (local, online, esetleg custom?)

Ez utóbbi ugyanis elég fontos, nem mindegy, hogy online microsoft accounttal, vagy csak a lokális gépen lévő felhasználónkkal szeretnénk bejelentkezni. Az interneten a legtöbb helyen azt a megoldást javasolják, hogy mentsük el a kapcsolatot rdp fájlba, és abba írjuk bele az alábbi sort:

enablecredsspsupport:i:0

Ezt azt eredményezi, hogy az mstsc nem akar majd felhasználónevet, és jelszót küldeni, hanem már azt is a remote sessionben kell beírnunk. Nem rossz, de a korrekt megoldás az, hogy a felhasználó típusát jelöljük a felhasználónév mezőben.

Lokális felhasználók esetén:

WORKGROUP\username

Online microsoft accountok esetén:

MicrosoftAccount\username

 

És láss csodát már működik is…