2012. január havi bejegyzések

Partíció formázása ext3-ra

Van egy kiváló ASUS WL-500 routerem, amiben azt szeretem legjobban, hogy külső USB-s diszket lehet rádugni és pikk-pakk kész a fájlszerver. Sajnos egy ideje azt tapasztaltam, hogy másolás közben a Windows Explorer gyakran elveszítette a kapcsolatot, miközben elég súlyosnak tűnő bejegyzések kerültek a router syslogjába az smbd-vel kapcsolatban, például:

write_socket_data: write failure. Error = Broken pipe
Error writing 64 bytes to client. -1. Exiting

Szerencsére a diszken VFAT fájlrendszer volt, így könnyen át lehetett tenni Windows alá, ahol a chkdsk talált pár hibát. Sok guglizás után arra jutottam, hogy a routerben lévő USB driver jobban szereti az ext2-ext3 fájlrendszereket, ami közül a journalig miatt én az ext3-at választottam. Na de hogy tudok egy diszket ext3-ra formázni? Mivel nem sok kedvem volt SSH alatt fdisk-kel, mounttal és a formázással bohóckodni, kényelmesebb megoldást találtam:

  1. Letöltöttem és kiírtam CD-re a GParted Live CD-t, ami mindössze 115 MB és nagyon gyorsan megvolt.
  2. Bootoltam a frissen sült CD-ről.
  3. A boot menüben: GParted Live (Default Settings)
  4. Policy for handling keymaps: Don’t touch keymap
  5. Which language do you prefer: 33 (US English)
  6. Which mode do you prefer: ö (ami a nullának felel meg, azaz Continue to start X to use GParted automatically)

Ezek után hamarosan betöltődött a GParted grafikus felülete, ami simán látta az USB-s diszket és gyerekjáték volt vele kattintgatva létrehozni az ext3-ra formázott partíciót.

Guglizás közben belefutottam néhány fájlrendszer meghajtóba, melyek segítségével Windows alól közvetlenül is elérhetjük a Linuxos partíciót. Nem próbáltam ki őket (nem szívesen telepítek drivereket), de még hasznos lehet:

A fájlrendszer váltás a jelek szerint segített, azóta a Windows Explorer és a Samba is vígan muzsikál.

 

Technorati-címkék: ,

A Connect igenis működik

Időnként én is szoktam szapulni a Microsoft Connect szolgáltatását, hiszen nem egyszer előfordul, hogy az ember beküld egy hibajelenséget, amire visszajön a By Design, Won’t fix, Postponed vagy valami hasonló válasz. De legyünk őszinték, ki nem állított még be hasonló választ a saját bug trackerében? És akkor egyszer csak jön egy Closed as Fixed válasz, ami elsöpör minden korábbi kellemetlen élményt.

November elején írtam arról, hogy milyen szomorú, hogy az IIS ApplicationPooldentity nem lehet SQL Server Agent job owner, mert elbukik a felhasználói fiók ellenőrzésén. Akkor be is küldtem ezt a hibát a Connectre, hogy legalább nyoma maradjon. Egy héten belül jött a standard “thank you – we are investigating” válasz, majd kértek további infókat, aztán a szokásos csönd, el is felejtettem a dolgot. Aztán most kapom a szívderítő választ:

Hey György
I just wanted to update you that the issue was fixed and you should see it in next major release, you actually can test it on SQL12 RC0 pre-release.
Thanks
Alex Grach [MSFT]

Mindezt úgy, hogy mindössze heten szavaztak erre a hibára (köszönöm mindenkinek). Like!

Szóval íme, itt az élő példa, hogy a Connect != /dev/null. Ha hibát találtok, küldjétek be!

 

Technorati-címkék: ,,

JSON sorosítás

Már régóta nyilvánvaló, hogy az AJAX a múlté, hiszen AJAJ van helyette. Kezdetben azért volt ez így, mert kín és szenvedés volt az XMLHttpRequest objektumot alacsonyszinten matatni, de aztán jött a jQuery és azóta minden rózsaszín. Az XML-t azonban teljesen jogosan leváltotta a JSON és azóta az Ajax elnevezés már nem is egészen helytálló.

Persze mióta mindenki JSON-t használ a kliens-szerver közötti kommunikációra, egyre gyakrabban merül fel a kérdés, hogy hogyan állítsunk elő szerver oldalon JSON-t és hogyan dolgozzuk fel a JSON-ban bejövő adatokat? .NET-ben szerencsére (?) van erre több lehetőség is:

Már az is elég szomorú, hogy egy frameworkön belül két osztály is szolgál ugyanarra, a nagyobb gond viszont az, hogy egyik sem tökéletes. Egyrészt sajnos mindkettőben vannak hibák, amik valahogy nem akarnak kijavulni több framework verzió óta, másrészt egyszerűen nem elég rugalmasak. Szóval rájuk férne egy kis pofozgatás, webfejlesztői szemmel mindenképp. Tudja ezt az ASP.NET MVC csapat is, csakhogy egyik névtér sem hozzájuk tartozik, így jár, aki out-of-band.

De kár szomorkodni, hiszen vannak kiváló megoldások a piacon, sőt a szabadpiacon! Ott van például a Json.NET osztálykönyvtár, ami már sok helyen bizonyított, ahol a beépített osztályok kevésnek bizonyultak. Ingyenes, rugalmas és még gyors is:

json-406-json-performance

Le a kalappal James Newton-King előtt, hogy egy ilyen hobbiból megírt és még szabadon elérhetővé is tette. Köszönjük.

Akkor most egy pillanatra képzeljük magunkat az MVC csapat helyébe: van egy funkció, ami nagyon kell, ám a beépített verzió nem ideális és nincs lehetőségük megjavítani, ámde van egy külső komponens, ami jónak tűnik. A külső komponensek amúgy is beváltak már ennél a csapatnál, elég csak a jQuery-re, jQuery Validationre és Modernizr-re gondolni, amik megjelennek a projekt sablonokban.

Hogy mi lesz a preferált megoldás az MVC4-ben, arról kár most találgatni (és amúgy se mondhatom meg az NDA miatt). Én mindenesetre azt mondom, aki JSONozik, annak ideje megismerni a Json.NET-et…

 

Technorati-címkék: ,,,

COMException: Illegal operation attempted on a registry key

COM is loveA COMException egy igazi klasszikus rémálom. Egyrészt ijesztő (“jajj, mit kezdjünk most ezzel?”), másrészt Champollion legyen a talpán, aki rájön, hogy igazából mi a baj. Persze a második gátlástalanul erősíti az elsőt.

Íme egy példa illusztrációként: adott egy webszerver, rajta egy ASP.NET-es alkalmazás, ami Active Directory-hoz kapcsolódik. A webhely tökéletesen működik, de a szerverre kerül egy másik web application is, ami után a DirectoryEntry konstruktor nem tud a címtárhoz kapcsolódni, helyette inkább elszáll ezzel a hibával:

System.Runtime.InteropServices.COMException (0x800703FA): Illegal operation attempted on a registry key that has been marked for deletion.

Pedig én aztán nem csináltam semmit, sem ezzel az alkalmazással, sem a címtárral, sem a registry-vel! Azért elég zavarba ejtő, az Event Logban persze semmi hasznos, a hibaüzenetben még kevésbé.

Hát akkor rajta, elő a Process Monitorral, az majd megmondja, hogy kinek melyik registry kulccsal van baja –  persze csak miután az ember leszűrte és átnyálazta a sok ezer sornyi logot. Azért előtte egy gyors apppool recycle, hátha… És bejött, azóta semmi baja a szervernek.

COM is not love.

 

Technorati-címkék: ,,

ASP.NET MVC 4 újdonságok 5 percben

logoHamarosan elérhető lesz az ASP.NET MVC 4 bétája, amit az ASPInsiders tagságnak köszönhetően már a múlt héten sikerült megszereznem. Nagyon sok kellemes újdonság van benne, közülük több is azonnal belopta magát a szívembe, ezért úgy döntöttem, hogy videó sorozatot készítek az újdonságokról. Pár részt már fel is vettem és amint feloldják az NDA-t, már teszem is ki őket a Youtube-ra.

Coming soon!

 

Technorati-címkék: ,,,

Az ASP élt, él és élni fog

Update: Kicsit félreérthető volt a vége, ezért kiegészítettem.

Már több, mint tíz éve itt a .NET, de a mai napig előfordul, hogy valakit ki kell javítanom, hogy “az bizony nem ASP, hanem ASP.NET”. Mondhatnánk, hogy szinte mindegy is, hiszen ki a fene izzad még mindig klasszikus ASP-vel? Márpedig vannak ilyen elvetemültek, nem is kevesen! Nem is olyan rég ismét előkerült egy cég, ahol nem csak hogy eszük ágában sincs váltani, hanem folyamatosan fejlesztik tovább a régi ASP-s alkalmazást. Őszinte részvétem…

Aki hasonló cipőben jár, annak mindenképp érdemes megnézni az ASP.NET Web Pages technológiát, mert arra sokkal könnyebb váltani, és akkor már legalább ott a teljes .NET arzenál a háttérben, amiről később tovább lehet lépni.

Persze ilyenkor felmerül a kérdés, hogy meddig mehet ez így tovább? Hát ha a Microsoftot kérdezzük, akkor még legalább 10 évig, ugyanis a Windows 8 éppúgy támogatni fogja a klasszikus ASP-t, mint a korábbi verziók. Ott a Developer Preview, ki lehet próbálni. Sőt, azt is megsúgom, hogy egyelőre tervbe se vették, hogy mikor akarnak megszabadulni tőle. Bármennyire is értelmetlennek és szomorúnak tűnik, hogy még mindig vannak fejlődő klasszikus ASP-s alkalmazások, ez kiválóan mutatja, hogy ha a Microsoftnál egyszer valami bekerül a support körforgásba, akkor az jó sokáig ott is marad és lehet rá számítani.

Aggódik még valaki a Silverlightos alkalmazások jövőjéért?

Technorati-címkék: ,,

MSG 8624: The query processor could not produce a query plan

Érdekes hibába futottunk bele már nem először: adott egy INSERT szkript, ami nagyon nem akar lefutni, az alábbi hibával örvendezteti meg a gazdáját:

Msg 8624, Level 16, State 1, Line 13
Internal Query Processor Error: The query processor could not produce a query plan. For more information, contact Customer Support Services.

Na ez az, amire az ember azt mondja, hogy könyörgöm, ez csak egy sima insert, mi ebben olyan nehéz? Úgy tűnik, hogy a probléma az idegen kulcsok és a persisted oszlopok környékén lehet, legalábbis erre utal az alábbi két Connect bug:

A hiba évek óta ismert, de azért még mindig sikerül reprodukálni, tessék csak szavazni rá, hátha egyszer megjavítják.

Szerencsére van workaround (én nem hívnám megoldásnak, de működik):

SET ANSI_NULLS ON
SET ANSI_PADDING ON
SET ANSI_WARNINGS ON
SET CONCAT_NULL_YIELDS_NULL ON
SET NUMERIC_ROUNDABORT OFF
SET QUOTED_IDENTIFIER ON
SET ARITHABORT ON

Az utolsó csak akkor kell, ha az adatbázis 80-as kompatibilitási módban van.

Remélem sikerült ezzel megkímélni másokat is pár órányi debuggolástól.