HAVIT Knowledge Base

Vývoj webových aplikací, .NET, SQL, návrh
Welcome to HAVIT Knowledge Base Sign in | Join | Help
-
Home Články Forums Obrázky Soubory

TechEd Barcelona 2008 - Day 3 - Středa

TLA317 Creating Custom LINQ Providers - LINQ to Anything

Zajímavá technická session s úvodem do tvorby vlastních LINQ providerů (Queryable). Z přednášky určitě stojí za probádání vzorový kód implementace LINQ to LDAP providera včetně parsování lambda-výrazů a sestavování dotazu LDAP. Pokud by se někdo pokoušel o vlastního providera, velká část kódu je do značné míry Copy-Paste, resp. velmi dobrým studijním materiálem.

WUX317 Nerdvana Annihilation: Improving Silverlight UX without out-of-the-box controls

Z půlky povídání o návrhu UI, které se vzdáleně blížilo včerejší session "Why software sucks", zbytek ukázka Silverlightu použitého na webu způsobem, který bych označil přinejmenším za předčasný (nahrazení DHTML při prezentaci pouhých textů). Session mě moc nezaujala.

TLA01-LNC IronRuby in Action

Odlehčené intro do projektu IronRuby, což je Microsoftí implementace jazyka Ruby s možnostmi integrace s .NET frameworkem postavené na dynamickém CLR. Řekněme, že to je to podle mě akademický výplod mizivého praktického uplatnění, který je prezentován jako "možnost pro programátory v Ruby, jak zůstat u svého jazyka a používat při tom .NET". Mohu-li programátorům Ruby doporučit, tak ať třetinu času, kterou by potřebovali na fungování s IronRubym věnují učení klasického C#, a ušetří si tím spoustu problémů (i když tím příjdou o svou výsadu minoritního jazyka a zařadí se do póvl-mainstreemu).

Jinak to považuji za research větev, z které se třeba něčeho dočkáme i v mainstreemech. Např. "monkey-patching" tříd, kdy se dodatečně doplňují membery (zejména metody) již existujících tříd je opravdu zajímavý mess a doufám, že v CLR zůstane jen u extension metod. 

DAT307 An in-depth look at the ADO.NET Entity Framework

Uff, tohle nemohl za "in-depth look" považovat snad ani někdo, kdo Entity Framework v životě neviděl. Řekl bych "introduction" a po pár minutách jsem přešel na OFC206 (kde jsem zbytek session litoval, že jsem tam nebyl od začátku).

OFC206 Open XML SDK Version 2 Overview and Architecture

Bohužel jsem tedy v naivní víře v DAT307 přišel o začátek, nicméně tím spíše mohu zaznamenat, že tato session rozhodně stojí za shlédnutí a budu hledat její video. Ve zkratce:

  • Open XML SDK v2 je strong-typed .NET API pro práci s Open XML dokumenty (v2 momentálně CTP bez produkční licence, verze 1 je poměrně o ničem, pokud jsem správně pochopil)
  • API nemá smysl popisovat, je obrovské asi jako OpenXML standard, nicméně za zmínku strojí následující nástroje (nejspíš stáhnutelné pod názvem Open XML Power Tools,´nebo součástí SDK - jak jsem přišel pozdě, tak nevím přesně):
    • Document Reflector - vezme OpenXML dokument a vygeneruje k němu C# kód, jak by se býval byl daný dokument vytvořil pomocí OpenXML SDK, skvělý nástroj - když nevím jak něco udělat, udělám si to ve Wordu/Excelu a podívám se, jaký kód mi to pro danou operaci vygeneruje.
    • OpenXML Diff - vezme dva OpenXML dokumenty a porovná je - vizuálně zobrazí jejich rozdíly. Opět dobré, pokud něco nevím, udělám změnu a podívám se, jak se to projevilo.
    • Class Explorer - hiearchický browser v třídách Open XML SDK s odkazy do dokumentace, atp.
  • Součástí session byly zajímavá dema, jejich zdrojáky se mohou hodit, např.:
    • vytahování dat z Excelových tabulek pomocí LINQ
    • manipulace Open XML dokumentů z PowerShellu
  • zaznělo, že na CodePlex existuje XSLT šablona pro převod OpenXML dokumentů na "nearly the same" HTML podobu - může se hodit, ještě nevím na co :-))

 

WUX315 Developing High Performance JavaScript, AJAX for Microsoft Internet Explorer 8

Zajímavá session o performance recomendations pro JavaScript, za připomenutí stojí:

  • symbols resolution - názvy se vyhodnocují v pořadí scopů 1. local, 2. global, 3. DOM, 4. expando (pořadí dle rychlosti vyhodnocení), abychom u nějaké proměnné dosáhli lokálního efektu, musí být explicitně deklarována,
  • DOM access - extrémně drahou operací jsou přístupy do DOM, pokud chceme například sestavovat kus HTML stránky, pak je efektivnější ho sestavit do lokální proměnné a následně přiřadit jedním DOM accessem do innerHTML, než ho skládat přímo v innerHTML; stejnětak pokud potřebujeme procházet nějakou kolekci elementů a zpracovávat ji, může být efektivnější vykopírpvat prvky z DOM do lokálního pole a zpracovávat dále z něj
  • built-in metody pro přístup do DOM (getDocumentById, nextSibling, ...) jsou obvykle mnohem rychlejší než vlastní alternativa (procházení kolekcí, ...)
  • v IE do verze 7 je drahé skládání textových řetězců (funguje jako v .NET) a je vhodnější použít Array, složky skládat pomocí push() a následně vše spojit jediným join()
  • statement switch je interpretován jako řetězec if-else, není tedy tak efektivní jako hash algoritmy běžných kompilerů (C#, ...), někdy může být efektivnější nahradit switch hash-tabulkou, nebo obdobnou alternativou,
  • pro rychlé vykreslení stránky by měly být všechny JScript odkazy na konci HTML kódu (pokud IE narazí na script, musí ho nejprve stáhnout a zjistit, jestli v něm není document.write()) a styly naopak na začátku HTML (styl by měl být definován vždy dřív, než je použit, jinak je přerušen progressive-rendering, aby se zabránilo probliknutí neformátované verze); IE8 se snaží problém se skripty trochu pokrýt spekulativními preloady.

Video ze session určitě stojí za shlédnutí, poučná doporučení.

WUX405 Common ASP.NET production issues and how to troubleshoot them with windbg

Zajímavé povídání o ladění problémů na produkčních webových serverech

  • http://blogs.msdn.com/tess - blog přednášející, mraky materiálů na toto téma, podklady z prezentace 
  • snímek problému na serveru si pořídíme ve formě memory-dumpu pomocí nástroje adplus - řídí se pomocí konfiguračních souborů a umožňuje snímat dumpy za různých podmínek (on-demand, on-crash, sběr .NET výjimek, atp.)
  • memory-dump následně analyzujeme pomocí Windows GUI symbolic debuggeru (windbg), přičemž je to nástroj, který umí krásné věci (např. zobrazit .NET callstack všech threadů našeho procesu, obsah paměti až do úrovně jednotlivých objektů a hodnot, sync-zámky atp.), ale ovládá se poměrně příšerně ála příkazová řádka; příkazy na blogu Tess, co jsem si tak v rychlosti stihl zapsat:
    • .loadby sos mscorwks (načtení sos.dll pro podporu .NET analýz)
    • .cmdtree c:\file.txt
    • !sos.help
    • !dso

...výborná ukázka, ze které nebylo možné si pamatovat podrobnosti, ale jen princip ladění a odkaz na blog, kde jsou detaily. 

Published 12. listopadu 2008 15:25 by Robert Haken
Filed under:

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

minority said:

V článku mě zaujala Vaše věta "Mohu-li programátorům Ruby doporučit, tak ať třetinu času, kterou by potřebovali na fungování s IronRubym věnují učení klasického C#, a ušetří si tím spoustu problémů". Je to opravdu úsměvné, jak si lidé myslí, že zrovna jejich jazyk je ten správný.

Nejsem žádný milovník ruby, ale ta Vaše formulace mě opravdu pobavila. Zkuste se jen zamyslet kde byla příčina MVC frameworku od Microsoftu a proč na to všichni microsoftí developeři tak spásně čekají? A přitom je MVC tak moc stará věc ....

listopadu 18, 2008 7:21
 

minority said:

Ještě jedna věc by mě zajímala. Proč se do C# postupně dostává tolik rysů z dynamických jazyků jako je Ruby? On to třeba zas takový akademický výplod zase nebude ;-)

listopadu 18, 2008 7:25
 

Robert Haken said:

to minority: Asi jste mě špatně pochopil. Já netvrdím, že Ruby je špatný a C# je ten jediný správný. Já tvrdím, že momentální implementace IronRuby od MS je pro praktické použití neefektivní (neproduktivní), a že to celé je a dlouho bude v takovém stavu, že pokud by to nějaký "rubysta" z jiné platformy považoval za použitelnou cestu k .NET, pak mu doporučuji přeskočit mordování s IronRuby a raději použít nějaký mainstream jazyk.

Jinak osobně si myslím, že high-level programovací jazyky jsou do značné míry rovnocenné a každý ať si to zapisuje v syntaxi, jaká mu vyhovuje (a pokud mu nevadí, že jako nováček v .NET nenajde v ruby jediný rozumný příklad, a že nebude prakticky s nikým schopen sdílet kód, pak ať klidně použije IronRuby).

Jinak každému, kdo si chce udělat vlastní názor doporučuji shlédnout video ze  session TLA01-LNC.

listopadu 18, 2008 7:49
 

Robert Haken said:

to minority: Jinak o ASP.NET MVC si také myslím své. Je to nezralá alternativa, která má k efektivní implementaci skutečných aplikací stále dost daleko, a sám MS ji na otázku scénářů vhodného použití dokáže obhájit jediným argumentem - lepší testovatelnost. Pro mě je to cena za testovatelnost zaplacená snížením efektivity implementace příliš vysoká.

listopadu 18, 2008 7:52
 

minority said:

Ano, tak to jsem Vás do značné míry asi špatně pochopil. V otázce ASP.NET MVC s Vámi polemizovat nechci. Myslím si, že koncept MVC byl na .NET potřeba, ale samozřejmě je otázkou v jaké to je stavu, což nemohu posoudit.

listopadu 18, 2008 8:01
 

Robert Haken said:

to minority: Jinak si samozřejmě myslím, že C# je pro scénáře, které používám, ten nejlepší jazyk. Kdybych si to myslel o jiném jazyku, tak ho používám. :-)))

listopadu 18, 2008 8:28
 

minority said:

Tak sám musíte nejlépe vědět jaký jazyk je pro Vás nejvhodnější. V JavaScriptu se také například dá napsat spoustu věcí, ale za jakou cenu :-))

listopadu 18, 2008 9:02

What do you think?

(required) 
(optional)
(required) 
Enter the code you see below

Submit