Monthly Archives: January 2013

T4MVC: ASP.NET MVC stringmentesen

Az ASP.NET MVC egyik kellemetlensége, hogy alapértelmezés szerint sok helyen stringekkel hivatkozunk a controllerekre, actionökre és view-kra. Aki valaha készített már ilyen projektet, az biztosan írt már az alábbihoz hasonló sort egy actionbe:

  return View( "Index" );

vagy épp egy view-ba:

  @Html.ActionLink( "Bejelentkezés", "Login" )

A szépséghibát a stringek jelentik, ugyanis ha ott hibázunk, az csak futási időben derül ki.

Ezen segít a T4MVC projekt, amit legegyszerűbben NuGet csomagként illeszthetünk be az alkalmazásunkba:

Ha már vannak a projektünkben controllerek, akkor ne lepődjünk meg, hogy a NuGet telepítő egy kicsit átírja őket:

Sőt kapunk néhány extra fájlt is a projektünkhöz:

Cserébe ezek után már típusosan hivatkozhatunk a nézetekre:

  return View( Views.Index );

az actionökre:

  @Html.ActionLink( "Bejelentkezés", MVC.Home.Login() )

és még sok minden másra, amiről bővebben a dokumentációból tájékozódhatunk.

Mivel a háttérben T4 template-ek alapján történik kódgenerálás, felmerülhet a kérdés, hogy mi történik, ha például felveszünk egy új actiont? Azt fogjuk tapasztalni, hogy simán hivatkozhatunk rá view-ból, még az IntelliSense is fel fogja kínálni, csak éppen futási időben fog elszállni ezzel a hibával (itt azért egy pillanatra elgondolkozhatunk, hogy vajon nem épp ezt akartuk-e elkerülni):

T4MVC was called incorrectly. You may need to force it to regenerate by right clicking on T4MVC.tt and choosing Run Custom Tool

Szerencsére nagyon beszédes hibaüzenet, és ha követjük, valóban meg is oldódik a probléma. Ha még ezzel sem szeretnénk foglalkozni, akkor használhatjuk az AutoT4MVC bővítményt, amely figyeli, hogy módosulnak-e a fájljaink, és szükség esetén automatikusan újrafuttatja a kód generátort.

Technorati-címkék: ASP.NET MVC,T4

UPC távirányító csere

9 Replies

Történt, hogy a UPC Mediabox távirányítójából kiesett az I(nformation) gomb. Ez elsőre nem tűnik nagy veszteségnek, de hamar rájön az ember, hogy nehéz nélküle élni. Irány az ügyfélszolgálat, ahol jó hosszú várakozás után szó nélkül 2 perc alatt kicserélték a távirányítót.

Az igazi nehézség otthon várt: minden kiválóan működött, kivéve azt az apró, ám el nem hanyagolható jelenséget, hogy a távirányító csak a TV hangerejét volt hajlandó állítani, a mediaboxét nem. Kép volt, de meg se mukkant.

Szerencsére a felhasználói kézikönyvben van egy Gyakran feltett kérdések fejezet, ahol pont van egy erre vonatkozó rész, ami azt írja, hogy olvassam el a használati útmutatót. Az már önmagában is elég rossz, hogy egy mezei távirányítóhoz használati útmutató kell, de nekiestem és beismerem, elolvastam. Kiderült, hogy a mediabox távirányítójával lehet a TV-t, videót is vezérelni, ha egyszer összehangolja az ember a kettőt. Az én esetemben gondolom az történt, hogy az előző tulajdonos vagy a gyár/szerviz összehangolta már egy hasonló TV-vel, és most ezt el kellene felejtetni vele. Erről persze szó sem esik a leírásban, az ügyfélszolgálatot pedig természetesen lehetetlen elérni, de az automatájuk felhívta a figyelmemet a weboldalukon található tudásbázisra, ahol ismét csak a használati útmutatóhoz irányítottak. Nem sok segítség.

Végül mi lett a megoldás? Hát persze, hogy a Google!

Keresés: upc távirányító hangerő

Első találat: A UPC távirányító miért nem szabályoz hangerőt?

A lényeg: a leírásban szereplő 991-es kóddal lehet automatikusan egymásra hangoltatni két készüléket, és úgy tűnik, hogy a 993-as kóddal lehet elfelejtetni a korábbit. Thx Mano85.

Ez segített, már működött a hangerő szabályozás, viszont valamilyen véletlen egybeesés folytán egy perc múlva lefagyott a mediabox. Sajnos megesik vele nem ritkán. Kikapcs-bekapcs, ám most kivételesen nem indult el, beleállt az InIt fázisba, mint a cövek, a TV pedig nem kapott jelet.

Az init már ismerős volt, nem egyszer előfordult, hogy – gondolom szoftver frissítés után – kérte a kütyü az országot és az aktiválási kódot, ám most csak a “Nincs jel” fázisig jutottunk el, ami ugye nem nagy kunszt, hiszen kikapcsolt mediabox esetén is ezt írja ki a TV.

Megint a Google segített, bár most nem elsőre:

Itt azt írták, hogy nyomjak UPC+OK-t egyszerre
Máshol meg azt, hogy 0000 OK-t
Megint máshol pedig azt, hogy OK

Nálam a 0000 OK működött, feljött az ország választó és utána ment minden simán. Arról fogalmam sincs, hogy az előtte előbb szándékosan, aztán inkább idegből végignyomkodott kombinációkkal mit szabadítottam rá az emberiségre.

Kicsit elgondolkoztam rajta, vajon milyen lenne a világ, ha a szoftvereinket is így készítenénk? Elég néhány univerzális gomb, azok megfelelő sorrendben és együttesen történő lenyomásával minden cél elérhető. A lehetséges funkciók egy részét dokumentálnánk, a többit pedig találja ki az, akinek szüksége van rá. Hamar eszembe jutott, hogy az ötletem nem eredeti, máris vannak ilyen szoftverek és weboldalak Mosolygó arc

Új kampányt hirdetek, legyen “használhatóság” a jelszó!

Technorati-címkék: usability

Firefox kontra UTF-8

3 Replies

Az Egyetem MSDNAA oldalának frissítésekor futottam bele egy érdekes jelenségbe: saját gépemen tesztelve az oldalak teljesen jól működtek, felmásolva a szerverre viszont nem egészen. Szinte az összes böngészőben rendben volt minden, kivéve Firefoxban, ahol zagyvaság jelent meg a magyar ékezetes karakterek helyett.

Ellenőriztem a fájlokat, korrektül UTF-8-ban voltak elmentve, még a byte-order-mark is ott volt az elején – amit mondjuk nem volt nehéz észrevenni, hiszen a Firefox lelkesen ki is rajzolta az oldal elejére: ï»¿

Mivel szép új HTML5 oldalakról van szó, ott virít bennük a <meta charset="utf-8" /> sor, sőt még a klasszikus Content-Type sort is beletettem, hiába.

A gyors ellenőrzések után vissza a kályhához, elő a Fiddlert, ahol már látszott is a hiba oka. Ez a fejléc sor jött a szervertől:

Content-Type: text/html; charset=iso-8859-1

Ezen a ponton megvilágosodtam és rájöttem, hogy a régi oldalak miért voltak UTF-8 helyett ISO-8859-1-ben elmentve: mert a webszerver ezt a charsetet kényszeríti rá! A fejlécben lévő információ pedig Firefox esetén felülírja az oldalban lévő beállítást.

Tekintve, hogy a site egy Apache szerveren fut shared hosting környezetben, ahol se ASP.NET, se PHP, se admin jogom, szerver oldali kódból nem tudtam felülírni a fejléc mezőt. A megoldás mégis egyszerű lett, csak ezt az egyetlen sort kellett a webhely gyökerében lévő .htaccess fájlba beleírni:

AddDefaultCharset UTF-8

A webhely gyökerében lévő beállítás szerencsére öröklődik az alkönyvtárakra is.

Technorati-címkék: Apache,encoding,Firefox

.NET állásinterjú témák

1 Reply

Korábban írtam már C# állásinterjú kérdésekről és általános .NET architect kérdésekről is, de az az igazság, hogy egy állásinterjún ennél sokkal szélesebb témakörök jöhetnek elő. Persze lehet C#-ból is olyat kérdezni, ami talán nem mindennapos (például Shallow copy vs. deep copy), de az az igazság, hogy SQL-es vagy webes kérdések éppúgy előfordulhatnak.

Chandan Kumar Sinha, aki Indiában dolgozik szoftver fejlesztőként, ezért úgy gondolta, hogy nem egy véges listát ír az állásinterjú kérdésekről, hanem egy blogon folyamatosan teszi közzé a szerinte fontos témákat.

A .NET Interview Cracker blogon heti két-három bejegyzés születik, amelyekben eddig C#, .NET, SQL és web szolgáltatásokat érintett. A cikkek nem hosszúak, és nem is kérdéseket tartalmaznak, hanem inkább összefoglalják az adott témához tartozó legfontosabb tudnivalókat. Ez a formátum haladóbbaknak is hasznos lehet, segít feleleveníteni és rendszerezni a régen tanultakat.

Technorati-címkék: C#,.NET,interview,test

A jQuery szakít a régi IE verziókkal

8 Replies

Ma megjelent a jQuery legújabb, 1.9 verziója és vele együtt a 2.0 verzió bétája. Bár a két verziónak ugyanaz az API-ja (pár dolgot az 1.9-ből éppúgy kivettek, mint a 2.0-ból), mégis óriási különbség van közöttük:

Az 1.9 verzió – a korábbiakhoz hasonlóan – fut Internet Explorer 6, 7 és 8 verziókon, ahogy ők mondják “oldIE”-n.
A 2.0 nem fog futni oldIE-n. Ez számos egyszerűsítést tett lehetővé, aminek köszönhetően a 2.0 verzió gyorsabb és kisebb lesz, mint az 1.9 verzió.

A Release Notes szerint a fejlesztők mindkét verziót támogatni fogják a jövőben, de én úgy sejtem, hogy ahogy az lenni szokott, ez nem lesz mindig így. Előbb-utóbb az 1.9 el fog avulni, az új funkciók pedig könnyen lehet, hogy csak a 2.0 verzióba fognak bekerülni.

Vajon ez kinek rosszabb, az IE-nek vagy a jQuery-nek? A fejlesztők fognak átállni a jQuery-ről más könyvtárra, vagy a weboldalak fognak lemondani a régi Internet Explorer támogatásáról?

Technorati-címkék: Internet Explorer,jQuery,JavaScript