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

Az én megvalósításomban az adatbázis nem a megszokott Microsoft SQL, hanem MySQL. A telepítés kicsit macerás volt egy idegesítő hiba és a konfiguráció nüanszai miatt, ráadásul mivel nem vagyok .Net fejlesztő és VS-ből soha nem próbáltam ilyen kapcsolatot létrehozni, IIS-ből sem volt könnyebb.

Kapásból vakvágányra futottam, mert Google-ban keresgéltem, megszegve ezzel az MS fejlesztők és rendszergazdák elsőszámú szabályát: használd a Support weboldalakat, mert sz@runk a google-ra és nem hagyjuk, hogy a jó megoldásokat első oldalon hozza. Szal’ elkezdtem behackelni ezt a göncöt: http://www.codeproject.com/KB/database/mysqlmembershipprovider.aspx Már az SQL táblák létrehozása egy katasztrófa, hagyjuk is.

A jó megoldást a MySQL saját connectora jelenti: Connector/Net 6.2: Nem kell félni az MSI installertől, kiválóan működik.

A Connector mellé installálni kell a MySQL ODBC Drivert is. Töltsük le a MySQL oldaláról, majd telepítsük.

IIS Managerben elég bonyolult a sok kattintgatás, ezért inkább postolok egy helyes, jól működő web.config kódot:

<!-- Előbb eltávolítjuk az alapértelmezetteket, mert az IIS hiányolja őket és a sajátunk nem fog működni-->
<connectionStrings>
        <remove name="LocalSqlServer" />
        <remove name="LocalMySqlServer" />
        <add name="LocalMySqlServer" connectionString="Datasource=localhost;Database=dbname;uid=username;pwd=password;" providerName="MySql.Data.MySqlClient" />
</connectionStrings>

<system.web>
    <roleManager enabled="true" defaultProvider="MySQLRoleProvider">
      <providers>
        <clear />
        <add name="MySQLRoleProvider" type="MySql.Web.Security.MySQLRoleProvider, MySql.Web, Version=6.0.3.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d" connectionStringName="LocalMySqlServer" applicationName="LoginControl" />
      </providers>
    </roleManager>

<!-- autogenerateschema="true", ha nem kézzel akarjuk létrehozni a táblákat..-->
 <membership defaultProvider="MySQLMembershipAppProvider">
       <providers>
        <clear />
        <add name="MySQLMembershipAppProvider" type="MySql.Web.Security.MySQLMembershipProvider, MySql.Web, Version=6.0.3.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d" autogenerateschema="true" connectionStringName="LocalMySqlServer" enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="false" applicationName="LoginControl" requiresUniqueEmail="true" passwordFormat="hashed" maxInvalidPasswordAttempts="7" minRequiredPasswordLength="7" minRequiredNonalphanumericCharacters="1" passwordAttemptWindow="10" passwordStrengthRegularExpression="" />
      </providers>
    </membership>

    <compilation>
      <assemblies>
        <add assembly="MySql.Data, Version=6.0.3.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d" />
      </assemblies>
    </compilation>

</system.web>

Jellegzetes hibalehetőségek, amikkel én is szívtam:

1. ODBC Dirver tényleg legyen rendben, akár teszteljük is, mielőtt bármit konfigurálnánk.

2. Ha az ODBC rendben, ne felejtsük a schema=”true”-t hozzáadni a MemberShip Providerhez, mert különben nem jönnek létre a szükséges táblák a MySQL adatbázisunkban.

3. Figyeljünk, hogy ne legyen hiba a connection stringben, nem szereti a jelszóban a különleges karaktereket.

Ha mindent jól csináltunk, az IIS Manager ASP.NET / .Net Users-be belépve egyrészt nem kapunk hibát, másrészt létrejönnek adatbázisunkban a szükséges táblák és akár meg is kezdhetjük a felhasználók feltöltését. Az IIS tökéletes felhasználókezelést nyújt, nemsokára posztolom az én Flexben készült “Fancy Remote” applikációmat, ami még fejlesztés alatt áll.

Telepítése nem túl bonyolult:
Töltsük le a http://www.codeplex.com/CustomBasicAuth weboldalról (az installert, ne a forrást).
Persze gondok lesznek, különben nem ínék róla
Az installer.cmd a gautil.exe-t használja, ami nagy marhaság a kedves fejlesztő részéről, hiszen a .Net Framework 2 óta ez a utility nincs benn a Frameworkben, csak az SDK-ban. Kiszolgálókra meg ugyebár mióta divat SDK-t pakolni :S Az MS hivatalos álláspontja egyébként az, hogy a GACUTIL egy fejlesztői eszköz, ezért is vette ki a Frameworkből.

Itt kicsit tétováztam, mert nem igazán tudtam, mire jó egyáltalán ez a kis programocska. Aztán kiderült, hogy igazából nincs rá szükség. Fogjuk a 3db dll fájlt és másoljuk a C:/Windows/assembly könyvtárba, így bekerülnek a GAC-ba. Majd az installer kikommentelt utolsó két parancsát futtassuk le parancssorból a fájlok mappájában:

iisschema.exe /install CustomBasicAuthentication_schema.xml

IisRegMgmt CustomBasicAuth LeastPrivilege.CustomBasicAuthentication.Management.CustomBasicAuthenticationModuleProvider LeastPrivilege.CustomBasicAuthentication.Management.dll

Voila, készen is vagyunk, az IISManager-ben a Site-unk Authentication panelján már ott kell lennie a Custom Basic Authentication opciónak is. Az Edit-re kattintva konfigurálhatjuk, hogy melyik providert használja. Tiltsuk le az összes többi Authentication módot és próbáljuk ki a böngészőből. Ha feldobja az autentikációs ablakot, akkor nyertünk. A sikeres bejelentkezéshez persze kell a működő provider is.

Ha esetleg nem működne a cucc, és még nincs a helyén, akkor az IIS Managerben a Modules panelon adjuk hozzá az installált modulokhoz a CustomBasicAuthentication-t is a legördülő listából.

Amit én szerettem volna az a következő:
1. WebDAV SSL titkosítással
2. Egy központi WebDAV root folder és abban Virtuális mappaként bemappolva a felhasználók Site-jai úgy, hogy a webdav root-hoz és más domainjai alatt lévő tartalomhoz se férjenek hozzá.
Az egyes hosztolt weboldalak elérései így néznének ki:
http://www.host.hu/webdav/domain1.hu
http://www.host.hu/webdav/domain2.hu

Az elképzelés tökéletesen működhetne, de nem ment elsőre a dolog..
A főbb lépések így néztek ki:
1. A host.hu/webdav/domain1.hu - virtuális mappa WebDav Authentication Rule-jai közé hozzáadtam a “test” nevű felhasználót.
2. Adtam neki WebDAV jogokat, innentől kezdve elméletileg van joga a virtuális könyvtár fizikai helyére és annak összes alkönyvtárára WebDAV-on keresztül.
3. Csatlakoztam a “test” nevű felhasználóval és rendben meg is jelent a domain1.hu könyvtár tartalma:

log/                   --        Tue, 20 Jan 2009 09:07:05 GMT
tmp/                   --        Tue, 20 Jan 2009 09:07:13 GMT
www/                   --        Wed, 28 Jan 2009 15:35:31 GMT

A log és tmp könyvtárakkal semmi gond, minden jog érvényesült. Viszont a www-re listázáskor hibát kaptam, nem érvényesültek rá a domain1.hu-ra kiadott jogok. Csak a www-re? Mivan? Miért is?

Mivel az IIS konfigurációja elosztott, több szinten definiálható, ezért amikor egy kérés jön a webszerverhez, ő gyorsan körbenéz minden beállítási szinten: megnézi az applicationHost.config fájlban az alapbeállításokat, érvényesíti, a location tagekben (ha van) a site konfigurációját, érvényesíti, egy szinttel lejjebb, a könyvtárstruktúrában elhelyezett web.config fájlokban keres, érvényesít és halad méglejjebb az almappák web.config-jaihoz, stb, stb.. Hopp! Ez lesz a baj!

Mivel a http://www.host.hu/domain1.hu/www mappa igazábol a szerveren hosztolt domain1.hu site root-ja, az ottani web.config fájlt is érvényesíteni szeretné függetlenül attól, hogy én WebDAV-on keresztül egy másik alkalmazásból hívom meg a könyvtár elemeit. Szeretne hozzáférni a web.config-hoz, de nyilván nem tud, innentől kezdve nagyon egyszerű dolgunk van, hiszen csak azt kell megakadályoznunk, hogy a domain1.hu alkönyvtárait és az azok alatti könyvtárak web.config fájljait is keresse az IIS. A legszebb az egészben, hogy ehhez csak annyit kell tennünk, hogy a domain1.hu virtuális könyvtárához hozzáadjuk az allowSubDirConfig=”false” paramétert az applicationHost.config központi konfigurációs fájlban.

A dolog működik, viszont óriási biztonsági rést üt. Gondolkozzunk el egy picit, hogy hogyan működik a WebDAV. A HTTP protokoll hátán utaznak az infok, a 80-as porton. Az IIS elkülöníti a WebDAV és sima HTTP kéréseket, jogosultságilag is, azzal nincs is gond, hogy a WebDAV jogokat csak a webdav/domain1.hu, webdav/domain2.hu stb.. virtuális mappákra és azok felhasználóira adom ki így megakadályozva, hogy egyik felhasználó a másik cuccai közt bóklásszon.
De ha ezt sima HTTP-n keresztül teszi, akkor autentikáció után a böngészőbe csak a mefelelő elérési utat kell bepötyögnie és bármilyen fájlhoz hozzáfér amit a virtuálsi WebDAV-os mappákkal bemappoltam. Azt mondanán, hogy ez sem gond, hiszen ezt közvetlenül mondjuk a domain1.hu/titok.html-en keresztül közvetlenül is megteheti. Pedig nem. Mivel a web.config fájlokban olyan autentikációs és authorizációs illetve átirányítási utasítások lehetnek, melyek elfednek bitonyos fájlokat a működő aplikációkban, ezért ha mi hatástalanítjuk a allowSubDirConfig-al, szabad az út az ilyen módon védett tartalomhoz. a http://www.host.hu/webdav/ felől érkezve.

Ezért mindenképp meg kell akadályoznunk, hogy a bejelentkezett felhasználó HTTP (nem WebDav) kéréssel elérje a könyvtárakat (persze a saját könyvtárát el kell, hogy érje, hiszen ha HTTP nincs, WebDAV sincs). A megoldás pofon egyszerű és szép is:

1. A webdav/ könyvtárunkat fosszuk meg az Authorization beállításoknál az Allow All-tól. Ezzel megakadályozva, hogy az autentikált felhasználó bármit is elérjen a könyvtáron belül.
2. Osszunk ki egy szinttel lejjebb a webdav/domain1.hu felhasználójának a “test” usernek egy Allow-t.

Kész a shared hosting webdav elérés is. Enjoy!
Felelőséget persze nem vállalok az itt leírtakért, mert csak részben érintem a biztonsági kérdéseket. Ezen kívül rengeteg egyéb követelménynek kell teljesülnie egy biztonságos kiszolgálón.

WGET: A unixos wget parancs nagyon hasznos, gyakran használjuk és éppen ezért windowson erősen érezhető a hiánya. A Windows CMD parancsai között nincs ilyen, helyette több alternatívát ismertetnék:

1. Wget.exe - Remek kis utility. Aki nem akar sokat szórakozni töltse le, másolja be valamelyik PATH mappába és már használhatja is úgy mint más rendszereken. Mivel a normál commandline-ban nem csak wget parancs nincs, hanem a szögfeldolgozási lehetőségek is igen gyérek, a visszakapott http válasszal, vagy fájlal már nem nagyon tudunk mit kezdeni. Ha mégi ilyen szándékaink vannak, más, szkriptelési megoldások után kell néznünk:

2. VBScript: Az alap, IXMLHTTPRequest interfészt használó HTTP kérést végrehajtó szkript alább látható. Nem többről van szó, mint egy http kérés indításáról és a válasz tartalmának kiíratásáról. A kikommentelt rész az url paraméterként való megadhatóságára szolgál ha CMD-ből, szeretnénk futtatni.

Option Explicit
On Error Resume Next

Dim url
url="http://blog.vargapeter.com"

'Dim paramz
'Set paramz = WScript.Arguments
'url = paramz(0)

Set objHTTP = CreateObject("MSXML2.XMLHTTP.3.0")
objHTTP.open "GET", url, false
objHTTP.send()
MsgBox objHTTP.responseText
Set objHTTP = Nothing

3. Powershell: Mivel PS-ből meg tudunk hívni .Net-es osztályokat, használjuk a System.Net.WebClient-et. A neve beszédes, van egy rakás metódusa és tulajdonsága. Lássunk egy egyszerű példát az előző kód mintájára:

$httpclient= new-object System.Net.WebClient
$httpclient.DownloadString("http://blog.vargapeter.com")

4. Mi van még? PS alatt azért jól el vagyunk látva, írtak többen is cmdleteket az egyszerűbb hívás érdekében:
WGet 2 for PowerShell
Jacobian’s wget for PowerShell

Hát ennyi.. használjuk azt a megoldást, ami céljainknak legjobban megfelel.
Holnap új téma, új szkriptek!

Az XMLRPCSerializer.as fájlban a 99. sor környékén nyomjunk egy ilyet és már működik is:

else if (tobject is Object){
         txmllist =  encodeStruct(tobject);
}

1. Telepítjük az uTorrent legfrissebb változatát.
2. Duplikáljuk az uTorrent mappáját a ProgramFiles mappában uTorrent2 néven.
3. Az intéző címsorába pötyögjük be: %appdata%uTorrent
4. Hozzunk létre egy új mappát uTorrent2 néven az %appdata%-n belül.
5. Másoljunk minden .dat fájlt a %appdata%uTorrent2 mappába.
6. Készítsünk egy parancsikont a C:Program FilesuTorrent2uTorrent.exe-re.
7. Nyissuk meg a parancsikon tulajdonságait és a Target-et módosítsuk erre: “C:Program FilesuTorrent2uTorrent.exe” /RECOVER.

Enjoy!


function elemLista(...items):void{
for( var i:int = 0; i < items.length; i++){
trace("Elem: ", items[i]);
}
}

Kimenet:
Elem: A
Elem: B
Elem: C
Elem: 1
Elem: 2
Elem: 3


Nagyon hasznos dolog, amint látható én gyakran használom.
Egy moduláris program interfészén dolgoztam, amikor szembejött egy probléma ezzel kapcsolatban. Mi van, ha egy tömböt akarok így, végtelen paraméterszerűen átadni a végtelenszámú argumentumot fogadó függvénynek?!
Nos, ha a tömböt közvetlenül adom át: elemLista(tomb:Array) az nem fog menni.
Viszont egy kis objektumorientált trükközéssel megoldható a probléma. Használjuk az apply metódust. Hülyén hangzik, de az OO programozásban minden objektum, így a függvényhívást, vagyis a függvényt magát is tudjuk objektumként kezelni. A következőt kell tennünk:


function elemLista(...items):void{
for( var i:int = 0; i < items.length; i++){
trace("Elem: ", items[i]);
}
}

Kimenet:
Elem: A
Elem: B
Elem: C
Elem: 1
Elem: 2
Elem: 3


Papaam! Már működik is. Nos, nekem ez egy óra kutakodásba került, remélem a kedves olvasó gyorsabban megtalálja

Múlt év Augusztusa óta nem volt időm, hogy leírjam ezt a beszámolót-kedvcsinálót.. 2008 nyarának utolsó hetében Katival egy hetet töltöttünk a Dachstein déli oldalán Ramsau falucska fölött.

(Berghotel Dachstein, háttérben a Dachstein déli fala)

Már áprilisban lefoglaltunk személyenként napi 23 euroért egy szobát a Berghotel Dachstein-ben teljes ellátással, ami utólag ár-érték arányban nagyon jó választásnak tűnt. A hotel 1680m-en van, a Türlwand Hütte és a Dachtein Seilbahn (felvonó) parkolója alatt, ahonnét a környék túrista- és klettersteig útjainak 90%-a indul. Az épület kicsit leharcolt, de tiszta, rengeteg pici szobával, amik két embernek éppen megfelelőek, főleg ha túrázni jönnek és nem lábatlógatni. Hotel-túristaszálló-Hütte közti átmenetnek mondanám jó kajával és bárral. A tulaj egy helybéli “Nagyfalas Géza” ahogy a veterán mászókat szoktuk emlegetni. Egyik nap beszélgettünk vele és kiderült, hogy mászok.. rögtön a kezembe is nyomott egy mászókalauzt amiben több általa épített út van. Mondta,hogy szívesen mászna velem, aztán kiderült, hogy régen sokat vadászott Sopronban és mutogatta, hogy milyen trófeákat lőtt a Soproni erdőben, szóval jó arc volt az öreg. A Schwartzenegeres kép az előszobában lóg más expedíciós képek társaságában. Igazi mászós szálloda, de sokan vannak olyanok akik pihenni, sétálgatni jönnek a környékre.

(Terminátor és a házigazda a hotel teraszán.. - kb 20 éve)

A 23 euroban teljes ellátás (este meleg étel) és ingyen italfogyasztás volt, ami a környékbeli 4 Euros tea árakat figyelembevéve bomba jó ár!  A szobánk déli fekvésű volt, csak úgy mint a Sonnen Terasse ahol a hotel lakói délutánként ropogósra süttethették magukat, miközben a gyönyörű kilátást élvezhették a dél felé magasodó hegyekre és Ramsau völgyére.

Indulás előtt mindketten jó alaposan utánanéztünk a környékbeli programoknak (én a Klettersteig utaknak - mászni nem szokott Kati, klettertseigezni se nagyon, de mutatott rá hajlandóságot -, Kati pedig az egyéb szabadidős, pihizős lehetőségeknek ) Az épülethez, és a közelben lévő felvonóhoz (Seilbahn), ami a Skywalk-ra és a gleccserre visz, fizetős úton lehet feljutni, autóval meglehetősen drágán (pontos összegre sajna nem emlékszem). Viszont lehet kapni bérletet és van olyan konstrukció is, hogy ha a Seilbahnt használod, nem kell fizetni. A buszon (mi ezzel jártunk) fölfelé a sofőrnél, autóval lefelé kell fizetni a (falu végén induló) Ramsau Strasse Mautstelle-nél.

Ramsau faluról annyit, hogy van egy műugró pályája, egy vegyesboltja, egy temploma és nyolc darab sportboltja. Minden házhoz tartozik egy legelő. Ez a falu központjában is így van, így sikerült 10 km hosszúra nyújtani a települést. Van uszoda is, gyönyörű panorámával és két medencével (úszógumi rulz). Épült nemrégiben egy kalandpark + nyáribob (kötelező!!) + strand + íjjász kombó a falu végén. A bob sínen fut lefelé egy hegyoldalról, durvább a vidámparki témáknál, ha rendesen ereszti az ember.. 5 euro egy menet ha 19 alattinak hazudod magad :D.. pfff.. Ezt egyébként mindenütt eljátszottuk, megéri, sokat lehet spórolni ha nem nézel ki vénnek Viszont számíts keresztkérdésekre pl. “melyik évben születtél?” ha sokat gondolkozol az évszámon, lebuktál.

Nah hát ennyit a környékről és a körülményekről.. igazából ezek a dolgok mind csak a pihenő napokon (kettő volt) kerültek szóba, mert a hét többi részét a Dachstein sziklái közt töltöttük. Tudni illik, hogy Katinak egy Rax-os klettersteig túrán kívül nem sok tapasztalata volt korábban a hegyekkel, de elég jó kondiban van, rendszeresen fut, edz, így nem volt gond egyik túrával és az A-B klettersteigekkel sem.

A túrák:

Türlwand Hütte(1692m) - Bachalm (1490m) - Ramsau(1250m) - Türlwand Hütte(1692m)

(Bachalm panoráma - Dachstein - déli fal)

Ez egy jó kis egész napos kb. 25-30 km-es kör volt, feltérképeztük a környéket a Duregg-Hierzegg hegy megkerülésével. Reggel 9 körül indultunk a hotelből  a Neustattalm irányába, ahonnét egy kényelmes sétaúton, a Dachstein fennséges falaival párhuzamosan a völgyben haladva egy-két óra alatt eljutottunk a Bachalmra. Itt vannak állítólag mormoták, érdemes őket megnézni! Mi sajnos ezt csak később tudtuk meg Kati nagy bánatára. A Bachalm privát bekötőútját sokszor keresztezve leereszkedtünk a völgybe és a már említett hegyet megkerülve egy meglehetősen unalmas, keresztbeálló tehenekkel nehezített a műutat szorosan követő ösvényen begyalogoltunk Ramsauba. A zoknibeszerzés után pedig nekivágtunk az egyik sípályának, hogy a Dachstein Haus - Austria Hütte útvonalon visszacaplassunk a hotelunkig. Ez kb 4-500 m szintkülönbséget is jelentett, de mégis kellemes és szép séta azoknak akik utána esetleg a fenti Türlwand Hütte parkolójából induló Seilbahnnal akarnak feljutni a csúcsra.

Tor - egész napos, könnyű túra (családdal is)

(Ez nem a Tor úton van, de innen látszik jól az útvinal: Katitól kicsit balra  a Raucheck hegyes csúcsa és a déli fal közötti hágón kell átkelni)

Nagyon jó kis útvonal a déli fal tövében egészen a Türlwand Hüttétől nyugatra magasodó Raucheck 2033m magasan lévő nyergéig. A túrát a Südwand Hütte felé indítottuk (1871m), majd onnét kicsit visszaereszkedve kőgörgetegeken átvágva, a mászóutak beszállói felé vezető ösvényeket követve értük el a Raucheck csúcsa alatti völgyet. A csúcs nevéhez hűen szinte mindig felhőket bökdös még jóidőben is. A völgyből egy tüdőkoptató szerpentin visz fel a nyeregre, ahonnét a Torstein szabdalt csúcsaira és a távolabbi hegyekre, hátrafordulva pedig a teljes déli falra és a Türlwand környékére van meseszép kilátás tárul elénk.

(Racheck alatti hágó)

Innen kellemes sétával megkerülve a Rauchecket a Bachalm felé, majd pedig azon a korábbi túránál említett bizonyos lankás úton haladva tértünk vissza kiindulási pontunkhoz. Sokan csinálják ezt a túrát az ellenkező irányba, mert úgy lefelé haladnak a nyereg előtti “brutális” emelkedőn.  Igazuk van.

Hunerscharte (2687m) A-B és Hunerkogel C-D Klettersteig - Skywalk

(Hölgy-völgy)

1000m-es szintkülönbségű túra, a végén nagyon izgalmas, kezdőknek is ajánlott könnyű klettersteiggel. Ismét csak a hotelünktől, azaz a Türlwand Hüttétől a Talstation-t (felvonó megállója) megkerülve a Südwandhütte felé vettük az irányt. A parkolóból is jól látható hüttét kb 40 perc alatt értük el, majd nekivágtunk a szép nagy falatnak ígérkező völgynek (615-ös út). Ebben a völgyben megy fel a felvonó drótkötele is. Mi alatta kanyarogva, kitartóan lihegve értük el a völgy utolsó, már sziklásabb harmadában induló Klettersteiget. Magunkraaggattuk a példásan komplett felszerelést, kantárokat, sisakokat és minden extrát, aztán nekivágtunk a néhol vicc számba menő Klettersteignek. Sokan ezt egyébként felszerelés nélkül teszik.. apukák, anyukák, nagymamák, nagytaták.. Sokszor gondolkoztam és beszélgettem másokkal is, hogy miért.. miért jó egy véletlen megcsúszás miatt meghalni?? Tudvalevő, hogy  “A hegyek közt rá lehet b@szni.. és sokan rá is b@sznak.” Hiába, kell a statisztika.. Másnap egyébként órákig körözött a Police helikopter a falnak ezen a részén, szal’ valószínűleg valaki tényleg rá is… Persze mi sem akasztgattunk minden szakaszon, de a kiszálló előtti befelé dőlő, agyonvasalt falon a felhőben -ami sokszor körülvett minket fölfelé menet- biztos be lettem volna tojva kantár nélkül.

A gleccserre felérve hó fogadott minket (ahogy azt egy rendes gleccseren szokás). Árnyékban egészen firnes, napos részeken pedig olvadozó volt az állaga. Ilyenkor is sielnek rajta, járnak is a gépek néha, egyengetik a koszos havat. A Hunerscharte klettersteig kiszállója a Skywalktól keleti irányban pár száz méterre van, ezt a távot havon csoszogva tettük meg, majd jött az okos ötletem, hogy mi lenne ha a skywalk korlátján fejeznénk be a túrát. Ugyanis van egy rövidke (kb 60-80m) C-D nehézségű via ferratta út a gleccserről a felvonó épületének korlátjáig. Rengeteg ember volt odafönn és mint valami messiást álltak körül minket, miközben egyik lábunkat a másik után lendítettük át a korláton. Mókás volt.. már csak a taps hiányzott. Magyarok is voltak fönn, a családapa nagyon megörült, mikor kiderült, hogy a kemény hegymászók (ezek mi voltunk) akiket figyeltek, szintén magyarok. Már menetközben és a megtekintett jégbarlangban (pénzkidobás, nem ajánlott) rákészültem a forró levesre, de kiderült, hogy a szelepes főzőmhöz nem csavaros-szelepes hanem rányomós-szelepes palackot sikerült utolsó pillanatban vennem még Sopronban. Szal’ a leveske kimaradt. Visszafelé csaltunk, mert a Seilbahnnal jöttünk.

Az utolsó napra hagytuk a legizgalmasabbat:

Edelgriess völgy - Koppenkarstein Klettersteig (A-B) függőhíddal

(Edelgriess völgy)

Szokás szerint a hoteltől indultunk, hegymászókhoz méltatlan 9 órás időpontban. A felvonó megállója alatt most jobbra tartottunk, mert a déli falat egy másik völgyből, az Edelgriess felől próbáltuk meghódítani. A Türlspitz csúcsok által elválasztott völgybe keleti irányban tudtunk felkapaszkodni, előbb legelőkön, majd törpefenyvesen, végül hosszú kőgörgetegeken átküzdve magunkat. A völgy lankásabb, meglehetősen kopár, de még így is egészen gyönyörű. Közepe felé jobbra kell fordulniuk akik a Ramsauer Klettersteiget választják, mi viszont végighaldtunk a völgyön és a végében nekivágtunk a szintén kopár, köves meredélynek. Az 572-es utat végig piros jelzés mutatja, nem lehet eltévedni. A Hinterer Türlspitz mögött Klettersteig kezdődik, de nem érdemes komolyan venni, mert csak 10m hosszú. Felérve egy kisebb gleccser, az Edelgriessgletscher terül el. Táblák itt nem nagyon vannak, mi a gleccser nyugati szélén, a sziklafal tövében tartottuk az északi-északnyugati irányt, mikor megtaláltuk az Austriascharte felé mutató táblákat és klettersteigszerű (sajnos ezen a szakaszon a drótkötelek mindenütt cafatokban lafogtak) köves kapaszkodót.

(A déli fal fölötti Koppenkarstein kitett, de könnyű klettesteig útvonalán)

A gleccser fölé emlkedve végre elérünk egy gerincre, ami nagyjából 1m széles és bizonyos részeken nincs biztosítva. Itt mutatja meg magát igazán a déli fal. Balra letekintve nagyjából 1000m-es mélység van alattunk, hihetetlen élmény volt Katinak, bár igazából az a mélység engem is picit megszédített, annak ellenére, hogy másztam már nagyfalon és hozzá vagyok szokva a magassághoz. A gerincen átkelve egy látszólag új úton elcsalhatjuk az út legizgalmasabb részét és egyből átsétálhatunk a Dachstein gleccserre, de mi úgy döntöttünk, hogy az Austriascharte (2736m) csúcsra indulunk. A felfelé vezető klettesteig nem nehéz, többnyire biztosított, bár a hó és a jég itt is sok helyen szétszabdalta a drótokat. A csúcs alatt találkozunk a Koppenkarstein csúcsról érkező azonos nevű via ferratta úttal, ami a déli fal gerincen megy végig a Hunerscharte-ig, azaz a fenti felvónóállomásig. Nagyon kitett, izgalmas út, kezdők számára bátran ajánlott jó időben. És itt jött a legizgibb rész, a kötélhíd!

(A függőhíd, balra a mélység felhőben, jobbra a gleccer és a Dachstein cúcs szintén felhőben)

Három kábel, 20m hosszan egy kb. 50m-es szakadékkal és kicsit balra további ezer méterrel a völgy, jobbra pedig további 100-al a gleccser felett. Kati nem akart átjönni (lehetőség van kerülni), de aztán megmutattam neki, hogy nincs mitől félni és rávettem. Nem bánta meg, nagyon nagy élmény volt neki! Az átkelés és fényképezkedés után továbbhaladtunk a gerincen. Kisebb felhők is voltak, amiket az áramlat az alattunk magasodó hatalmas sziklafalnak nyomva fújt felénk. Egészen mesebéli volt a felhők felett-között járni a jellegzetes magashegyi királykék égbolt alatt. A kilátás pedig a völgy és a gleccser irányába is lélegzetelállító volt!  Visszafelé megint a felvonót használtuk, mert én speciel utálok lefelé tülekedni a jó időben igencsak forgalmas könnyebb klettersteig utakon.

Egy áttekintő térkép a déli fal klettesteig útjairól + Tor útvonal családi, pihenő kirándulásnak.

A böngészőbe ezt írjuk: http://valami.vargapeter.com/index.html
A kiszolgálás valós helye mindkét esetben:  http://vargapeter.com/valami/index.html.

Redirect

Eredmény:  http://domain.hu/valami/index.html

<rule name="aldomain" stopProcessing="true">
     <match url="^(.*)$" ignoreCase="false" />
     <conditions logicalGrouping="MatchAny">
           <add input="{HTTP_HOST}" pattern="^valami.vargapeter.com" />
     </conditions>
     <action type="Redirect" url="http://www.vargapeter.com/valami" redirectType="Permanent" />
</rule>

Rewrite

Eredmény: http://valami.domain.hu/index.html

<rule name="aldomain" stopProcessing="true">
    <match url="(.*)" />
    <conditions logicalGrouping="MatchAll">
        <add input="{HTTP_HOST}" pattern="^valami.vargapeter.com(.*)" />
    </conditions>
    <action type="Rewrite" url="valami/{R:1}" />
</rule>

Fontos, hogy az aldomainek minden esetben konfigurálva legyenek a DNS szervereken és az IIS-ben pedig a webhely (Site) kötéseihez -utálom ezt a szót- (bindings) hozzá legyenek adva.

A Rewrite talán érdekesebb picit, ezért még egy kis regexpel tarkított kódrészletet is bemutatnék, amivel praktikusan kezelhetjük aldomainjeink átirányítását. A szabály lényege, hogy a valami.vargapeter.com domaint a wwwroot/_sub/valami könyvtárra irányítja. Így nem kell öt szabályt létrehoznunk, ha öt domainünk van és külön-külön megadni a valós kiszolgálási helyüket, hanem “rendszerezve” a _sub mappában az aldomain első tagjával megegyező nevű mappa lesz a subwwwroot-juk.

<rule name="SubDomain" stopProcessing="true">
    <match url="(.*)" />
    <conditions logicalGrouping="MatchAll">
        <add input="{HTTP_HOST}" pattern="^(.+).vargapeter.com(.*)" />
    </conditions>
    <action type="Rewrite" url="_sub/{C:1}/{R:1}" />
</rule>

Elkezdtem hát keresni egy olyan kényelmes Air applikációkkal is használható megoldást, ami a kliens és a szerver közti adatforgalmat sniffeli. Rá is akadtam a Charles nevezetű web debugging proxyra. Segítségével minden adatforgalmat nyomon tudunk követni, nem kell a szerveren kilogolni vagy más körülményes módszerekhez folyamodni.

A program OSX, Linux és Windows programra is letölthető a készítők weboldalán: Charles

A saját rendszerről röviden:
Van egy 10-20 honlapból összerakott optimalizálási halmaz amit rámbíztak. Egy fő honlap, + sok kis microsite, amik a fő honlapot nyomják előre és az egyes “szakterületeket” lefedik/részletezik. + az Adwords amit a költségek miatt nem szívesen alkalmazunk, csak ha muszáj.

Elég jó eredményeket sikerült eddig elérni adwords nélkül is, de sajnos vannak olyan kulcsszavak amiknél akkora a verseny és olyan “nagyok” vannak elöttünk, hogy csak lassan vagy kevés eredményünk van. Ilyenkor jön az Adsense, adott költségkerettel, csak a fontos szavakra a garantált megjelenés érdekében. Viszont nyilván ezekről szeretnénk tudni, hogy mennyire térülnek meg.

Az Adwords egy bazi nagy pénznyelő tud lenni, ha az ember nem néz rá legalább hetente és nem mélyed el a kezelésében eléggé. Csak nyomod bele a pénzt, látod, hogy kattintottak, aztán szevasz. Hogy az illető hová jutott és mit csinált a honlapon, arról már semmit sem tudsz. Itt jön képbe az Analytics!

Az Analytics-et egy nagyon jó statisztikai rendszerré fejlesztették ki Gugliék az utóbbi egy évben. Integrálódott az Adwordsbe is (vagy fordítva?) ami az Adwords felhasználók számára visszajelzést nyújt reklámokra költött pénzük hatékonyságáról.

Adwords fiókunkat a következő módon köthetjük össze az Analytics rendszerével: Google Súgó
Ha sikerült, várjunk néhány napot. Ha szépen jönnek az adatok a fizetett látogatókról, akkor a cikk további része már nem is érdekes. Örüljünk, figyeljünk, döntsünk pénzünkről. Ha az adatok nem érkeznek meg és egyértelműen lehetetlen, hogy 0 fizetett látogatónk van, akkor gondolkozzunk el, hogy nem mi rontottunk-e el valamit még a weboldal programozásakor..

A lehetséges problémák felkutatásához ismerjük meg a konverziókövetés technikai hátterét:

Mi történik a hirdetésre kattintás után?
A Google hirdetésre kattintás után a google saját url-je hívódik meg, regisztrálja a kattintást, annak költségét, stb.. és átirányít a Cél URL-re. Az Adwords hirdetések esetén a Google un. Cél-URL automatikus címkézését használja. Ez a gyakorlatban így néz ki: www.celurl.hu/?gclid=abc123

A legrosszabb dolog ami történhet, hogy a látogató megérkezett weboldalunkra, a pénzt levonták, de nem lát semmit!

Előfordul, hogy a a webhelyünk tiltja a paraméterek használatát, mert mondjuk ilyen url-eket használunk az optimalizáció miatt: http://weboldalunk.hu/utazas/magyarorszag.html és a programozáskora a paraméterek keveredésének megelőzése, vagy biztonsági szempontok miatt letiltották a “?” után megadható url paramétereket.
Két lehetőségünk van, az egyik, hogy letiltjuk a gclid használatát, de ezzel lemondunk a nyomonkövetésről is egyben. Nyilván mi nem akarjuk csak úgy vaktában szórni a lét, tehát a szimpatikusabb megoldást választjuk: programozunk. Engedélyezünk.

A látogató megérkezik, de erről mi nem értesülünk.
A paraméter nincs tiltva, de nem “jelenik” meg a Google Analytics tracker kódja számára. Ennek leggyakoribb oka megint az url-ek környékén keresendő:

http://weboldalunk.hu/utazas/magyarorszag.html webcímet nem mappákkal és html fájlokkal értük el, hanem  mod_rewrite (apache) vagy url_rewrite (IIS) átirányításokat használunk a “keresőbarát” url-ek felépítéséhez. Viszont arra nem figyeltünk, hogy a http://weboldalunk.hu/utazas/magyarorszag.html?gclid=abc123 cím is átirányítódjon. Sajnos ebben az esetnen is kicsit programozgatnunk kell, hogy a get paramétereket is benyelje regexpünk.

Ha minden hasonló hibát kiküszöböltünk, akkor az Analytics fiókunkban szépen meg fognak jelenni a fizetett forgalmi adatok is. Ez természetesen legalább 1 nap elteltével történik, ahogy a statisztikai adatok frissülnek.

Lássuk csak, mit kell tennünk:

1. Csatlakozzunk az MSSQL szerverünkhöz a Management Studio-n keresztül.

2. Válasszuk ki az adatbázist amiről biztonsági mentéseket akarunk készíteni.

3. A helyi menüből (jobb klikk) válasszuk a Tasks / Back Up.. funkciót.

4. A Back Up Database párbeszédablakban adjunk meg egy tetszőleges nevet a Backup Set-nek és a Destination listához adjuk hozzá annak a könyvtárnak az elérési útját ahová a backup fájlt szeretnénk menteni.

5. Baloldalt az Options részben állítsuk be, hogy a generált backup fájl tartalmához a visszaállítás hozzáírja-e az adatbázis tartalmát, vagy felülírja azt. Ha azt szeretnénk, hogy felülírja: “Append to an existing backup set”. Figyeljünk a fájlméretre! Ha nagy az adatbázisunk gondoskodjunk megfelelő méretű tárterületről a mentési periódus függvényében. Ha azt szeretnénk, hogy mindig csak a legutóbbi adatok legyenek a fájlban, válasszuk az “Overwrite all existing backup sets” opciót.

6. Érdemes lehet itt bejelölni még a “Verify backup when finished” és a “Checksum before..” funkciókat, ha paranoidok vagyunk érzékeny adatainkat illetően.

7. A későbbi futtatásokhoz szükség lesz az imént elvégzett beállítások adataival generált SQL fájlra. A Script gomb melletti legördülő menüből válasszuk a “Script action to File” opciót és mentsük el valahová a fájlt. Ha jól dolgoztunk, a bal alsó sarokban megjelenik egy helyes kis “Scripting completed succesfully.” felirat.

8. Ha leOKézzuk az ablakot, az első backup meg is kell, hogy történjen.

9. Az elkészített sql fájlt a parancssori Sqlcmd alkalmazáson keresztül fogjuk futtatni, ami a Microsoft SQL Server Native Client nevezetű eszköz fedőneve. Mindezt kézenfekvően egy batch fájlon keresztül. Készítsünk egy új szövegfájlt (Jegyzettömb), és a következő tartalommal mentsük el .bat kiterjesztéssel:

 sqlcmd -S .\SQLEXPRESS -i "C:\scripts\mssqlbackup\backup.sql"

10. Próbáljuk ki parancssorból, hogy működik-e.

11. Ha sikerült lefuttatnunk a batch scriptünket, a Windows Task Scheduler segítségével ütemezzük futtatását. A batch fájlba más utasításokat is írhatunk így egészen komplex backup scriptet készíthetünk.

Cool huh?

Tisztában vagyok vele, hogy ez nem mindenkit dob fel úgy mint engem, ezért itt egy “sírva röhögős” videó, hogy titeket is beragyogjon a “Napsugár”!