Szlovák kis és nagybetűk ascii hex kódja
(csak az angol abc-hez képest extra karakterek):

Á – 00C1
Ä – 00C4
Č – 010C
Ď – 010E
É – 00C9
Í – 00CD
Ĺ – 0139
Ľ – 013D
Ň – 0147
Ó – 00D3
Ô – 00D4
Ŕ – 0158
Š – 0160
Ť – 0164
Ú – 00DA
Ý – 00DD
Ž – 017D

á – 00E1
ä – 00E4
č – 010D
ď – 010F
é – 00E9
í – 00ED
ĺ – 013A
ľ – 013E
ň – 0148
ó – 00F3
ô – 00F4
ŕ – 0159
š – 0161
ť – 0165
ú – 00FA
ý – 00FD
ž – 017E

OSX alatt ezt a következő paranccsal Terminal-ból megtehetjük (OSX 10.5+):

dscacheutil -flushcache

Korábbi OSX (10.4) esetén:

lookupd -flushcache

Windows alatt parancssorba (futtatás:cmd):

ipconfig /flushdns

OSX és linux alá is van működő megoldás:
rtmpdump (osx/linux/win) parancssori program. Kicsit kényelmetlenebb a használata, mert előbb ki kell bogarásznod az rtmp streaming url-t az oldal forrásából, aztán parancssorban felparaméterezni a progit. Viszont automatizált letöltésre emiatt kiválló. Osx 10.7 Lion alá itt egy bináris telepítő, hogy ne kelljen Xcode-al befordítani.

A levelezésemben ugyan 2004-es keltezésű az első levél, de a közel 30GB méret így is gyanús volt.. max. 10GB-ra saccoltam volna az 5 gmail fiókot összesen. Az óriási méret oka, hogy az OSX Mail mappa és a Gmail “tag” koncepciója nem igazán kompatibilis.

Van például Gmail-ben egy “Összes levél” tag, amely teljesen külön szinkronizálódik le egy-egy IMAP kéréskor egy Mail-es mappába, így gyakorlatilag minden levelünk legalább kétszer lesz meg. De hasonló a helyzet a Csillagozott levelekkel és más tagekkel is.

Szerencsére van megoldás az értelmetlenül használt tárterület visszaszerzésére és a rengeteg felesleges háttérszinkronizáció elkerülésére.

A Google vagyis a Gmail kivételesen tényleg a barátunk.. csak jelentkezzünk be fiókunkba és az email beállítások között a Címkék fülön vegyük ki a “Megjelenítés IMAP-en” pipát minden olyan címke mögül, amit nem akarunk szinkronizálni IMAP-en keresztül.

A hiba oka az, hogy a .air fájlokat az IIS MIME listája nem tartalmazza, így nem is szolgálja ki. A megoldás pofon egyszerű, adjunk hozzá az IIS Manager szerver beállításai között a MIME Type részben egy új típust:

Add..
File name extension: air
MIME Type: application/vnd.adobe.air-application-installer-package+zip

Sony NEX 5
Sony E Pancake f2.8 16mm
Minolta f1.4 50mm

Music credits: She – Atomic

A módszer lényege, hogy a két Dropbox példány más-más home folderral fut. A szkript készít hozzá egy új alkalmazás csomagot is, melyet ha hozzáadunk a System Preferences  / Accounts / Login items listához, akkor mindkét példány automatikusan indulni fog bejelentkezés után.

Az angol nyelvű leirás után volt egy mondat, amit szabad fordításban idéznék:

“Ne legyél paraszt, ne használj 10 ingyenes Dropbox accountot ezzel a módszerrel!” Köszi.

mkdir -p /Users/$USER/Applications/DropboxAltStarter.app/Contents/MacOS/

cat <<EOF >/Users/$USER/Applications/DropboxAltStarter.app/Contents/Info.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>CFBundlePackageType</key>
<string>APPL</string>
<key>CFBundleExecutable</key>
<string>DropboxAltStarter</string>
<key>LSUIElement</key>
<string>1</string>
</dict>
</plist>
EOF

cat <<EOF >/Users/$USER/Applications/DropboxAltStarter.app/Contents/MacOS/DropboxAltStarter
#!/bin/bash
# Assumes you have Dropbox in /Applications
HOME=/Users/$USER/.dropbox-alt /Applications/Dropbox.app/Contents/MacOS/Dropbox
EOF

chmod 755 /Users/$USER/Applications/DropboxAltStarter.app/Contents/MacOS/DropboxAltStarter

Mivel többnyire hegyek között járunk, internet elérés nincs.. helyette sms-ben küldjük a twitter üziket. Sajnos direktbe nem lehet sem a Twitterre, sem pedig a Facebookra SMS-t küldeni, mert Magyarországon nem elérhetőek ezek a szolgáltatások. (F*ck Twitter! F*ckbook!)

Van egy magyar twitter app, a Twittelo.hu ami részben megoldotta a problémánkat.. beregisztrálsz a twitter accountoddal, megadod a telefonszámodat és onnantól kezdve ha a twittelo  telefonszámára küldesz valamit sms-ben, az egyböl kikerül a twitter csatornába is. A dolog szépséghibája, hogy egy twitter accounthoz csak egy telefonszám tartozhat.. mi meg vagyunk huszonakárhányan..

Sokat keresgéltem ingyenes sms gatewayek után kutatva, de nem sok ilyen van, ingyen meg pláne nem.. Aztán rátaláltam a Connectotel M-Mail szolgáltatására, melynek segítségével telefonról sms-en keresztül bárkinek tudok emailt küldeni.

Van az egyesületnek Facebook accountja, ahol szintén meg szeretnénk jeleníteni az üzeneteket. Erre van is lehetőség a Facebook via email szolgáltatással, ami úgy működik, hogy kapsz egy mail címet a facebooktól és amit oda küldesz az szépen megjelenik az üzenőfaladon.. A dolog szépséghibája, hogy ilyen email címet kapsz: valami87masvalami@m.facebook.com Ember legyen a talpán aki ezt megjegyzi és -10 fokban bepötyögi a telefonba..

Peti a hegyekben van, írni akar valamit twitterre.. előkapja a telefont és bepötyögi sms üzenetként:

1. uzenet@summitsport.hu Itt vagyok a hegyekben!

2. Elküldi az SMS-t az M-Mail telefonszámára.

3. Az M-Mail az SMS szövegét elküldi a uzenet@summitsport.hu-ra no-reply@connectotel.com feladóként.

4. Az uzenet@summitsport.hu  forwardolja az üzenetet a Facebookos katyvasz email címre és Facebookon már kinn is az üzi.

6. Facebook üzeneteinket egyszerűen megjeleníthetjük Twitteren is, ha a Facebook – Twitter fantáziadús alkalmazását használjuk: http://www.facebook.com/twitter/

Twitter felől is meg lehet közelíteni a dolgot.. előbb twitterre érkezik meg emailben (Tweetymail segítségével) az üzenet, majd Twitterről a Selective Twitter FB alkalmazással Facebookra. Persze ez bonyolultabb, de ha valakinek pont ez kell, akkor csak rajta!

Időzóna.. A php.ini kapott több új direktívát, ilyen a date.timezone mostantól kötelező beállítás is. Állítsuk be a php.ini-ben tehát a következőt:

date.timezone = Europe/Budapest

Localhost és mysql esete.. Install után próbálgattam lefuttatni néhány weboldalamat, de nem ment.. jobban megvizsgálva, csak a mysql-t használó oldalak nem mentek, így gyanakodni kezdtem a mysql modulra. Az viszont rendben betöltődött, látszólag semmi gondja nem volt.. Némi guglizás után kiderült, hogy 5.3.1 óta a php valamiért nem bírja értelmezi az oprendszertől visszakapott localhost címeket, ha több mint egy ip van hozzárendelve. Így a localhost nem “fordul le” 127.0.0.1-re. Két bugfix kínálkozik, egyik sem a legszebb megoldás..

a.) localhost helyett ezentúl 127.0.0.1-et használunk adatbázis csatlakozáskor.

b.) átírjuk a hosts fájlunkat, amit a C:\Windows\System32\drivers\etc\alatt találunk:

::1             localhost

A fenti sort kommenteljük ki!

New windows specifikus, de ide tartozik, hogy az 5.3-as verzióban több függvényt is halálra ítéltek, az ítéletet viszont még nem hajtották végre. Az ilyen függvényeket ‘deprecated’ módba rakták, azaz használhatjuk, de egy új, “DEPRECATED ” típusú hiba figyelmeztet rá. Részletesen: http://www.php.net/manual/en/migration53.deprecated.php olvashatsz az érintett fügvényekről és régi-új megfelelőikről.

Találtam egy valóban működő és nagyon egyszerű megoldást:

PRAM Reset.. A gép indulásakor nyomjuk hosszan az ALMA + ALT + P + R kombinációt, amíg a gép újra nem indul (újra megszólal a boot dallam).

A PRAM resetelése a gép alapbeállításainak visszaállítását jelenti. A PRAM-ban olyan információk tárolódnak mint a képernyő színmélysége, felbontása, virtális mem. beállítások, kernel panic log, stb.. Alapesetben ezt nem érdemes piszkálni, de ha lassulást észlelünk bootoláskor, akkor nagy az esély rá, hogy a PRAM konfigurációjának hibája okozza azt.

1. Maga az install automatikus, letöltjük az ImageMagick honlapjáról a nekünk megfelelő Windows Binary installert és elindítjuk. Ha nem tudod melyik a neked megfelelő, akkor válaszd a ImageMagick-X.X.X-X-Q16-windows-dll.exe változatot.

2. Az installer alapbeállításban hozzáadja a progit a system path-hoz, így parancssorból könnyen használható a progi. Az installer utolsó ablakában van is egy teszt példa az image magick logójával. Ezt érdemes lefuttatni, hogy működik-e a dolog magában.

3. Jöhet a php-s kiegészítő dll, amit innen tölthetünk le:  http://snaps.php.net/win32/
Válasszuk a saját php verziónknak megfelelő kiadású peclX.X -win32-latest.zip fájlt és guberáljuk ki belőle a php_imagick.dll állományt! Másoljuk a php könyvtárának extension mappájába!

4. A php még nem tudja, hogy nekünk van ImageMagick progink a gépen, mondjuk meg neki! A php.ini fájlba vegyük fel a következő sorokat:

extension=php_imagick.dll

5. Indítsuk újra szervert, hogy a php.ini fájl feldolgozásra kerüljön!

6. Teszteljük!
teszt.php fájl tartalma első lépésben:

<?php phpinfo();?>

Futtatás után a phpinfo-ban szerepelnie kell egy Imagick résznek. Ha nem szerepel, akkor elrontottuk az installálást valahol. Ha szerepel, akkor próbáljuk ki:

A teszt.jpg-t másoljuk a teszt.php mellé, aminek a tartalma legyen:

<?php header('Content-type: image/jpeg');
$image = new Imagick('teszt.jpg');
$image->thumbnailImage(100, 0);
echo $image; ?>

Az Imagemagick egyik nagy előnye, hogy a php exec paranccsal lehetőség van a parancssoros feldolgozásra, azaz nem a php futtatja a képek átalakítását, hanem egy külön windows programszál. Erről majd máskor..

A levelezés migrációja nem mondható bonyolultnak, néhány új MX és CNAME rekord beállítására van csak szükség domainünk NS szerverein, létre kell hoznunk a kívánt email (domain) felhasználókat, esetlegesen áttölteni a régi leveleiket, aliasokat és csoportos kézbesítéseket létrehozhzni, stb, stb..

A migrációt követően viszont van néhány kellemetlen dolog, amik megoldásával el kell játszani egy darabig, főleg ha nem tudjuk mi is igazából a probléma.
Lássuk, nálam milyen problémák jöttek elő és azokra milyen megoldásokat találtam:

1. probléma: PHP levélküldés nem működik a domaint kiszolgáló webszerveren, SPAM-be kerül a címzettnél.

Ezzel a problémával nagy valószínűséggel szinte mindenki találkozik, aki weboldalt is hosztol egy másik szerveren a GoogleApps-al használt domain alatt. Nálam a mailszerver és a webszerver is egy vason volt korábban, ilyen esteben a php.ini-ben és a mailszerveren megadott beállítások relative egyszerűek, a php mail() függvény teszi a dolgát a lokális SMTP-n keresztül, nem is kell vele foglalkoznunk.

De mi van, ha a domaint valósan kiszolgáló MTA fizikailag egy másik szerverre, jelen esetben a Google Apps szervereire kerül? Ha megmarad a mailszerver használhatjuk annak SMTP-jét, vagy telepítünk valamilyen mini SMTP szervert  a webszerver mellé! Így a levélküldés működik szépen, csak az okosabb SPAM szűrők ki fogják dobni a címzett oldalán összes levelünket. Miért is?
Egyszerűen azért, mert a  szűrő csak annyit lát, hogy a domainem.hu MX rekordja nem arra a szerverre mutat,  amiről a levél érkezik. A Gmail szűrője (nagyon helyesen) ezt figyeli, rosszabb esetben törli és soha nem kapjuk meg, jobb esetben felcimkézi SPAM cimkével a levelet. Ha nem tenné, bárki küldözgethetne nekünk saját domainem.hu-s címünkkel leveleket..

A megoldás:

SPF rekord. Az SPF (Sender Policy Framework) TXT rekordok segítségével szabályozhatjuk DNS szinten, hogy mely szerverek küldhetnek domainünk alól levelet. Sok próbálkozás és a Google által ajánlott megoldás helyett végül a következő SPF rekord került beállításra nálam és azóta rendben mennek a dolgok:

v=spf1 a mx a:000.000.000.000 include:_spf.google.com include:aspmx.googlemail.com ~all

A 000.000.000.000 helyére a webszerver IP címét írjuk! Azét a szerverét, ahonnét php mail()-el küldeni akarunk.
Fontos! Az all végződés előtti karakter nem kötőjel (-) hanem hullám karakter!
A fenti SPF rekord beállításával működik a php-ből indított levelek küldése, nem kerülnek SPAM-be a címzettnél.

2.probléma: SPAM levelek és a POP3

A Gmailben nem lehet kikapcsolni a SPAM szűrést. Alapértelmezetten minden fiókban van egy “Spam” mappa, illetve Gmail címke, amelyet minden beérkező levél megkap. Így a bejövő levelek közt nem jelennek meg, csak a SPAM mappában (címke alatt). Innen a levelek egyébként 30 nap elteltével automatikusan törlődnek is, tehát érdemes gyakran ellenőrizni..

Ha a Gmail felületét használjuk, ott van a mappa (címke), bármikor megnézhetjük,  semmi gond. Sőt IMAP protokoll használatával is szépen el lehet érni a címkét mint IMAP mappa.
Viszont a POP3 egy régi protokoll, csak arra képes, hogy a bejövő (INBOX) leveleket letöltse. Sok cégnél ragaszkodnak a POP-hoz, ezért a problémára valamilyen megoldást kellett keresnem:

A megoldás:

Sajnos csak olyan lehetőségünk van, amivel a SPAM szűrést mellőznünk kell. Persze ez arra a minimális SPAM mennyiségre vonatkozik, ami egy átlagos gmail fiókba érkezik.. (nálam napi 1-2 levél 3 ráirányított címmel). Rengeteg SPAM-et már eleve át sem enged a Gmail levélszemét szűrője és eldobja kézbesítés előtt.

A megoldás lényege, hogy létrehozunk egy Gmail szűrőt, ami a Spam mappa helyett a bejövő mailek közé rakja a levelet, így a POP kliens le tudja tölteni:

1. Hozzunk létre a Gmail / Beállítások / Szűrők menüben egy újat!
2.“Tartalmazza a következő szavakat:” nevű mező tartalma legyen ez:  is:spam
3. Tovább, majd jelöljük ki a “Soha ne legyen spam” opciót.
4. Done. Enjoy the SPAM!

Folyt. köv.

Download here the fixed file: wppt.php.zip

Please note:
This is NOT a crossplatform fix, only works under IIS!

Instructions:
1. Replace the original wppt.php with the unarchived.
2. If  the wp-content/uploads/wp-post-thumbnail/ directory doesn’t exist, create it!
3. Enjoy the fixed plugin!

If this bugfix saved your life or something like that, please send me some beer or donate (on the sidebar)!

Thank you!

$mail->IsSMTP();
$mail->Host = "ssl://smtp.gmail.com";
$mail->Port = 465;
$mail->SMTPAuth = true;
$mail->Username = "username@gmail.com";
$mail->Password = "password";

Van egy ViewStack komponensünk (MyViewStack), ebben pedig szépen elnevezett gyermek elemek. Elnevezés alatt azt értem, hogy mindegyiknek van saját “id”-je. Szeretnénk, hogy ne csak hagyományos módon az index alapján  ( MyViewStack.selectedIndex=1) lehessen elérni, hanem a “Stack” id-je alapján, amit stringként közlünk a megjelenítő metódussal.

A metódus adott: MyViewStack.selectedChild=, viszont a bemenet nyilván nem lehet egy sima változónév, Container-re kell hivatkoznunk. Naív módon próbálkoztam ilyen flashes közhelyekkel: this[target] és társai..

Persze nem ment. Mivel Container kellett neki minden áron, beimportáltam az  mx.core.Container csomagot és rájöttem, hogy mennyire  szépen meg lehet ezek után oldani a problémát:

import mx.core.Container;
private function showTarget(target:String) : void
{
    MyViewStack.selectedChild = Container(MyViewStack.getChildByName(target)) ;
}

Kb. fél éve volt egy BÉT előadás a tőzsde működéséről, alapfogalmakról, amit végighallgattam. Érdekes volt, akkor regisztráltam az updown.com-ra is. Akkor 1-2 hétig játszogattam vele, jópofának tűnt. Aztán se időm nem volt, se kedvem hozzá, nem foglalkoztam vele.
Benne maradt kb 100.000 USD részvényekben. A többi alaptőkét nem fektettem be. Jelenleg 1.165.000 USD-m van játékpénzben. Elgondolkodtató, nem? Szinte random módon kiválasztott cégek részvényeiről van szó, amikről pénzügyi szempontból semmit nem hallottam eddig, nem figyelem a híreket és egy grafikonjukat sem nézegettem még trendelemzési szándékkal. Hagytam őket érlelődni 5 hónapot és mi lett belőle? Dupla annyi pénz, sőt 1,5x-ese a befektetett összegnek. Ezek után örülnöm kellene a garantált <10 %-ékoknak? Most akkor mi legyen, tőzsdézzek?

0. Hol az efelvételi? Október 15-e éjjel (a jelentkezés első napja): Nézem a felvi.hu-t… mindenütt kinn a szöveg, hogy hogyan jelentkezz, mit adj meg, hova klikkelj, de az eFelvételi menüpont hiányzik. Okt. 16 de.: még mindig semmi, hívom az ügyfélszolgálatot, hogy bocsánat, lehet, hogy én vagyok a hülye, de nem találom az efelvételi menüpontot.
“Ja, az még nincs aktiválva.” “Hmm.. és mikor várható? ” “Őőőő talán a holnapi napon. De ha nem, akkor hétfőig biztosan.” “Ja, jó.. köszönöm. Viszhall!” Kiváncsi lennék, hogy ha én 3 nappal a jelentkezési határidő után jelentkeznék, azt elfogadnák-e.

1. Dokumentumfeltöltés esetén, ha túl nagy a fájl, benyom az iframe-be egy Bad Request HTTP error böszme feliratot.. Se hibakezelés, se semmi.. a szegény hétköznapi diák meg jöjjön rá mivan..

2. Lejárt session.. ajaxos művelet esetén kiokádja a div-be újra az egész oldalt.. Site in a div effect, értem én..

3. Ügyfélkapu hitelesítés.. na ez a legszebb, komolyan.. SSL error. Rossz a tanúsítvány, de nem csak szimplán rossz, hanem durván.. én ilyet még nem láttam.. Kb. 18-at kellett klikkelnem Firefoxban mire letöltötte és elfogadta az ócska tanúsítványt. Ok, én tudom, hogy ez a programozók, rendszergazdák hanyagsága, de egy ÁLLAMI cég tanúsítványa legyen már rendben könyörgöm!! Főleg ha azon a személyes adataimat hitelesítem. Miért neveljük szerencsétlen felhasználókat arra, hogy lesz@rják a tiltó és figyelmeztető üzeneteket?!

+1 a ráadás. OTP fizetés.. Fizetek, jön az SMS, 9essze’ levonva a számláról. Böngészőben szép kis HTTP error. Visszakavarodok a felvi.hu-ra.. látom, a felületen továbbra is “Önnek 9000 Ft díjtartozása van.” Ekkor a jelentkezés folyamata során harmadszor hívom az ügyfélszolgálatot.. Azonnal felveszik, mondom mi a gond. 10 msp múlva már mondja is a srác, hogy minden rendben, jóváírták az összeget, hamarosan a felületen is ezt látom majd. Elköszön.

Leteszem, aztán elgondolkodok.. Nem is érdekelte, hogy hibás a fizetési rendszer.. Feltételezem az ügyfélkapus hitelesítésnél felugró tanúsítványablakokkal sem bírkózott meg mindenki, arról is tudnak.. és tudjátok mi van? Leszarják. Leszarják, mert na és? Mi van, ha nem megy.. max beadod papíron, vagy nem leszel jövőre egyetemista. Ez az ami baromira dühítő az egészben.. na meg az, hogy a főnökeik, meg az ő főnökeik is így gondolkoznak.

De legalább a support gyors