Kilépés a BME-ről

Ha úgy döntöttél, hogy elhagyod az Egyetemet, és ezt a feletteseiddel is sikeresen megbeszélted, akkor még vár rád egy adminisztrációs tortúra. A tanszéki adminisztrációból meg fogod kapni az ún. Kilépő Lapot, amire pecséteket kell gyűjtened az Egyetem különböző osztályaitól, nagyjából egy tucatnyit. Attól függően, hogy mikor jártál utoljára a campus különböző épületeiben, ez akár nosztalgikus élmény is lehet, de többnyire inkább tájfutáshoz hasonlít.

Bár a lapon szerepel, hogy mit hol keress, íme még néhány segítség, hogy te is tarthasd a 90 perces szintidőt:

A telefonközpont irodája a D épületben a porta mögötti mini-folyosón található. Arról lehet megismerni, hogy a falon van egy telefon 🙂 Amikor ott jártam, akkor egy papírlapra ki volt írva, hogy a kilépéshez melyik melléken kell betelefonálni. Ha nem találsz oda, akkor a portán a telefonközpontot kérdezd, ne a TIO-t, mert esetleg átirányítanak az R épületbe. Ja, és a legfontosabb, hogy csak délelőtt, 8-12 óra között fogadnak.

Az orvosi rendelő hivatalosan a T épületben van, de ne menj be a T épület főbejáratán, mert onnan nem lehet bejutni az orvosi rendelőbe. Bejárat a H épület felől a földszinten. Sokat gondolkodtam, hogy egyáltalán miért kell odamenni, talán megállapítják, hogy a közalkalmazotti jogviszonyom során nem hülyültem meg (teljesen)? De nem, mert az orvos annyit sem kérdez, hogy “hogy van?”, csak aláírja a papírt, és közli, hogy a kartonodat nem adják ki, csak ha másik orvos írásban kéri. De ehhez a pecsételéshez feltétlenül képzett orvos kell, tehát rendelési időben menj. A recepciós pult nem üzemel, csak simán be kell menni a dokihoz (mindegy melyikhez), amikor te következel.

A KTH-ban az R épületben sorszámhúzós rendszer van az aulában, de ez ne tévesszen meg még akkor sem, ha a masinán van “Egyéb ügyek” opció is. Nem kell számot húzni, csak menj be a hatos szobába.

A könyvtári könyveket oda vidd vissza, ahonnan elhoztad őket, pontosabban oda, ahova tartoznak, tehát például az I épületben lévő szakolvasóba. Szuper, közös informatikai rendszere van a könyvtárnak, amivel bárhol meg tudják neked mondani, hogy van-e tartozásod, (sőt a könyvtári kártyádon lévő vonalkóddal ezt magad is kiderítheted a könyvtár weboldalán), de az a pecsét, amit a kilépő lapra kell ütni, az csak a központi könyvtár épületében van, tehát oda is el kell zarándokolnod. A bejáratnál lévő zöld ablakoknál kaphatod meg. (Most már érted, hogy a bejárat fölötti átjárót miért hívják Sóhajok hídjának? 😉 )

Az A épületben azon a szinten, ahol a belépő kártyádat kellene leadnod, választhatod azt, hogy nem ott adod le, hanem majd a tanszéken. Így megvan a lehetőséged, hogy szépen visszasétálj, és kényelmesen kihajts a garázsból. Ha egész évre befizetted a parkolási díjat, akkor megadhatod a számlaszámodat, és megígérik, hogy az időarányosan fennmaradó részt visszautalják. Erre egy hetes átfutási időt ígértek, meglátjuk.

Bármennyire is azt mondja mindenki, hogy a lapon lévő sorrendben haladj végig, ez teljesen lényegtelen. Mivel az A épületben szinte minden szinten meg kell állnod, célszerű azt utoljára hagyni. Ott azonban nem tudsz sorban végigmenni az emeleteken, mert a legvégén a lapot a 4. emeleten kell leadnod.

Miután leadtad a lapot, nem kapsz az égvilágon semmit. Csak egy ígéretet, hogy továbbítani fogják azt a MÁK-ba (hetente csak kétszer megy oda posta), akik azt feldolgozzák, majd visszaküldik a papírjaidat az Egyetemre, akik azt postázni fogják a te nevedre. Állítólag ez másfél hét alatt lemegy, hát majd meglátjuk, mint ahogy azt is, hogy ez mennyire lesz gond az új munkahelyen.

Összességében az egész procedúrában az a szép, hogy Te egyáltalán nem kellesz hozzá, tökéletesen megoldható lenne a dolog belső kézbesítéssel, vagy egyszerűen elektronikusan, papírmentesen. A pozitívum viszont az, hogy mindenhol percek alatt megkapod a pecsétet (miután sorra kerültél), és közben sétálsz egy jót a friss levegőn, ráadásul velem mindenhol készségesek, kedvesek voltak.

Talán mert tudják, hogy egy nap ők is ebben a cipőben fognak járni?

 

Technorati-címkék: BME

Utolsó napom a BME-n

Úgy döntöttem, hogy augusztus végén új fejezetet kezdek, és 14 év után elhagyom az Egyetemet.

Tizennégy év olyan hosszú idő, hogy nehéz teljes pontossággal visszatekinteni, mi minden is történt ennyi idő alatt. Az biztos, hogy sokat köszönhetek a Tanszéknek, a közegnek, ami lehetővé tette, hogy annyi remek projektben vegyek részt. Hogy csak egyet említsek, együtt csináltuk végig a .NET hazai bevezetését, és aki ott volt, emlékezhet még az induló készletekre:

Rengeteg élő eseményt szerveztünk ez idő alatt, a “Rendezvenyek” mappámban közel 200 almappa található. Volt néhány formabontó is, például amikor az előadás során összerakott pizzarendelő alkalmazás olyan kiválóan működött, hogy a futár valóban kihozta az illatozó pizzákat, és olyan is, hogy a közönség soraiból sorsoltunk ki valakit társ előadónak. Akkoriban még a termékbejelentések is nagyot szóltak, a Visual Studio 2005 Launch például rockos stílusban ment a Kongresszusi Központban:

Sokat gondolkodtunk egy közösségibb esemény kitalálásán is, végül nálunk született meg a Win The Web 24 órás programozói verseny ötlete, és mi is szerveztük az elsőt 2007-ben:

Íme a szervező csapat a díjátadón:

Számos nagyszerű kollégával dolgozhattam együtt, néha éjt nappallá téve:

Közülük sokan már korábban elhagyták az Egyetemet, és szintén távozott számos olyan diák, akit volt szerencsém tanítani ez elmúlt években. Sokukkal találkozom rendezvényeken, és jó hallani, amikor elmondják, hogy hasznát vették a nálunk tanultaknak. A visszajelzéseknek, legyenek azok bíztatóak vagy kreatív kritikák, mindig örültem, mert segítettek jobbá tenni az órákat, előadásokat. Sőt, volt úgy, hogy a falra is kikerültem velük:

Konzulensként nagyon sokat tanultam a hallgatóktól, és számtalanszor sajnáltam, amikor valakivel véget ért a közös munka. Persze nincs jobb érzés annál, mint amikor záróvizsga után kijön az ember védésről, és azt mondhatja a hallgatójának, hogy “Gratulálok, Mérnök Úr!” 🙂 Ez olyan, amit az Egyetemen kívül biztosan nem lehet megtapasztalni.

Vannak szerencsére olyan dolgok is, amik az Egyetemtől függetlenül velem maradnak. Megmarad például ez a blog, meg terveim szerint úgy általában minden olyan tevékenység, ami a Microsoft regionális igazgatói és Most Valuable Professional (MVP) címhez kapcsolódik már tíz éve:

Ahogy egy barátom fogalmazott, nem a Holdra megyek, megtaláltok 🙂

Hétfőn új időszámítás kezdődik, viszlát BME, helló LogMeIn!

 

ui. 1:

Nosztalgiázók kedvéért: Az Egyetemen vannak nagyon állandó dolgok, például a Goldmann menza semmit nem változott másfél évtized alatt, sőt még a Goldmann szelet is pont ugyanolyan:

 

ui. 2:

Kilépők kedvéért: Az Egyetemről kilépni nem annyira egyszerű, de erről majd egy másik cikkben…

 

Technorati-címkék: BME

Visual Studio “14” CTP SxS

Sorra jelennek meg a Visual Studio következő változatának előzetesei, ún. CTP, azaz Community Technology Preview formában. A CTP-k célja, hogy a fejlesztőcsapat minél korábban kapjon visszajelzéseket az újabb funkciók működéséről, ennek megfelelően ezekre koncentrálnak, nem pedig arra, hogy minden korábban bevezetett funkció is helyesen működjön. Simán előfordulhat, hogy egy korábbi verzióban már stabilan működő funkció egy CTP-ben elromlik (lásd Release Notes). Semmi gond, nem kell aggódni, a következő stabil release-re biztosan ki fogják javítani (főleg akkor, ha jelentjük a hibát). Ezzel teljesen összhangban a Microsoft nem csak hogy hivatalosan nem támogatja a CTP verziókat, de egy CTP telepítésével az egész “gép” támogatása megszűnik.

A legjobb megoldás a CTP kipróbálására a virtuális gép. Sajnos a Visual Studio csapat nem tesz elérhetővé telepített és előre konfigurált virtuális gépeket, aminek a fő oka, hogy így a telepítés folyamatát is sokan tesztelik világszerte különféle környezetekben. Azure előfizetéssel rendelkezők azonban kényelmes helyzetben vannak, mert számukra a Virtual Machine Gallery-ben elérhetőek ilyen konfigurációk.

Mi a helyzet a bátrak módszerével, a side-by-side telepítéssel? Természetesen a végleges verziót lehet majd a korábbi verzió mellé telepíteni, azonban CTP esetén ez fokozottan kockázatos. A VS “14” CTP 1 telepítője nem is engedte ezt, de mivel a csapat folyamatosan dolgozik a kapcsolódó problémák megoldásán, ezért a CTP 2-től már technikailag ugyan lehet side-by-side telepíteni, továbbra is az az ajánlás, hogy teszt gépen célszerű kipróbálni.

Side-by-side telepíteni nem kell félnetek jó lesz én nem ellenzem.

 

Technorati-címkék: Visual Studio,vNext

Mixed content warning

Szomorú, amikor így széthullik egy oldal a böngészőben, például Chrome-ban:

Hogy miért? Hát nem nyilvánvaló, ott van a magyarázat. Segítek:

Úgy hívják, hogy mixed content warning, és warning, azaz figyelmeztetés létére nem éppen feltűnő. Lássuk ugyanezt Firefoxban:

Megvan?

Az Internet Explorer kevésbé finomkodik, azonnal a felhívja a felhasználó figyelmét:

Bár itt nem egy pajzs ikont kell keresgélnünk (amit egyébként túl sokszor, túl sok mindenre használtak már), hanem rögtön kapunk egy szöveges üzenetet, semennyivel sem jobb a helyzet. Ezt az üzenetet, és úgy általában a problémát, ugyanis egy átlagos felhasználó nem érti. Sőt, nem csak hogy a felhasználók nem értik, de a fejlesztők sincsenek tisztában a biztonsági vonatkozásokkal, különben nem lennének ilyen problémás oldalak.

Pedig arra kellene csak figyelni, hogy ha az oldal https:// protokollon töltődik be, akkor az oldalra betöltődő összes (igen, az összes) tartalom is https-en jöjjön, ne legyen egyetlen http:// link sem az oldal kódjában. Ha külső domainről töltesz be tartalmat, és nem tudsz relatív URL-t használni, akkor kezdd az URL-t “//”-rel, és a böngésző azt a protokollt fogja használni, amit az oldal is használ. Ezt a hívják, hogy “protocol relative”, vagy “scheme relative” vagy “scheme-less relative” URL, és már az URI általános formáját leíró RFC 3986-ban is szerepel (2005. január), és természetesen a böngészők is értik.

Ideje lenne kijavítgatni az oldalainkat, a böngészőknek pedig előbb-utóbb teljesen blokkolni az ilyen defektes oldalakat.

 

Technorati-címkék: security,browser,SSL

Hány kérés kell egy authentikációhoz?

Adott egy webszolgáltatás, amiről tudjuk, hogy csak Basic hitelesítéssel érhető el, de ez nem gond, hiszen szerencsére .NET-ben a generált proxy osztály Credentials tulajdonságán keresztül könnyű beállítani a szükséges felhasználónevet és jelszót:

MyService ws = new MyService
{
    Credentials = new NetworkCredential( "user", "password" )
};

Az ember azt gondolná, hogy ennek hatására olyan HTTP kérés megy majd a webszolgáltatás felé, amely tartalmazza az authenkációhoz szükséges adatokat, de a valóságban sajnos nem ez történik. Először elmegy egy olyan kérés, amiben nincs Authorization fejléc, azután ha a szerver ezt zokon veszi és 401 Authenticate válasszal tér vissza, akkor a kliens küld egy újabb kérést, ezúttal mellékelve hozzá a felhasználónevet és a jelszót. Az eredmény tehát dupla forgalom. Ha ez nem szimpatikus, és persze miért is lenne az, akkor jól jöhet a PreAuthenticate tulajdonság:

MyService ws = new MyService
{
    Credentials = new NetworkCredential( "user", "password" ),
    PreAuthenticate = true
};

 

Technorati-címkék: webservice,security

PHP-s webszolgáltatás hívása .NET-ből

Úgy alakult, hogy .NET-ből kellett egy PHP-ban készült webszolgáltatást meghívnom standard SOAP interfészen keresztül, de ismét bebizonyosodott, hogy a Simple Object Access Protocolban a “simple” egyszerűen nem igaz, ugyanis a két fél összereszelése nem ment teljesen simán.

A hívás eredményeként a kliens 400 Bad Request státuszkódot kapott vissza, ami önmagában nem sokat segített a hibakeresésben. Az Apache webszerver naplójában ugyan volt egy Invalid URI in request bejegyzés, de ez sem vitt közelebb a megoldáshoz.

Mint már oly sokszor, most is a Fiddler segített. Megnézve vele a HTTP forgalmat gyanús lett, hogy a kérésben szerepel egy Expect: 100-continue fejléc, amiről később kiderült, hogy a PHP-s webszolgáltatás nem tud vele mit kezdeni. Ez egy elég érdekes fejléc, arra találták ki, hogy a kliens megkérhesse a szervert, hogy még a body felküldése előtt kiértékelje a kérésben szereplő fejléc mezőket, és egy 100 Continue válasszal jelezze, ha a fejlécek alapján hajlandó lesz feldolgozni a kérést, és a kliens bátran küldheti a body-t (bővebben lásd RFC 2616 8.2.3). Magyarul a klasszikus kérés-válasz sorrendet szépen fel lehet vele borítani:

Kliens –> Szerver:

POST example.com HTTP/1.1
kérés fejlécek
Expect: 100-Continue

Szerver –> Kliens:

HTTP/1.1 100 Continue
válasz fejlécek

Kliens –> Szerver:

kérés body

Szerver –> Kliens:

HTTP/1.1 200 OK
válasz fejlécek
válasz body

A .NET kliens mindig elküldi az Expect: 100-Continue fejléc sort, hogy spóroljon a hálózati forgalommal, sajnos azonban a jelek szerint nem minden szerver támogatja ezt a csavarást. Ezt a viselkedést a ServicePointManager osztály Expect100Continue tulajdonsága segítségével lehet felüldefiniálni:

ServicePointManager.Expect100Continue = false;

Még az is lehet, hogy így lesz gyorsabb a kódunk, hiszen a HttpWebRequest osztály alapértelmezés szerint 350 milliszekundumot vár a Continue válaszra.

 

Technorati-címkék: webszolgáltatás,webservice,PHP,SOAP