Daily Archives: 2007.01.31. 13:13

Egyetlen gondolat a licencelésről: ASP.NET AJAX

Időnként előfordul, hogy megkeresnek licenceléssel kapcsolatos kérdéssel, pedig arra szinte biztosan nem fogok tudni válaszolni. Ahogy a Microsoft Regional Director levelezőlistán szokták emlegetni, "you need a PhD to understand Microsoft licensing".

Most azonban mégis akadt egy kivétel, mégpedig az ASP.NET AJAX megjelenése kapcsán. A Microsoftnál végre valaki észbekapott és sikerült egy oldalas licenc szövegeket írniuk!

Az ASP.NET 2.0 AJAX Extensions csomag immár forráskóddal együtt letölthető, és a forráskódra a Microsoft Reference License (Ms-RL) vonatkozik, ami tényleg csak 1 oldal. A lényeg: azért adta ki a Microsoft az Atlas forráskódját és a PDB fájlokat, hogy egyszerűbb legyen a fejlesztők élete, lehessen szépen debuggolni. (Sőt, még az is lehet, hogy éppen az ASP.NET AJAX-ot felhasználó fejlesztők találnak meg így olyan hibákat, amiket a product team nem vett észre :)) Magyarul bele lehet nézni, de nem szabad módosítani, terjeszteni vagy újrafordítani. Végre nem kell Reflectorozni!

Az Atlas másik része, a Microsoft AJAX Library szintén forráskóddal együtt elérhető (másként nem is lehet, hiszen JavaScript fájlokról van szó), ezekre a Microsoft Permissive License (Ms-PL) vonatkozik, ami szintén nem hosszú. Ahogy a nevében is benne van, ez megenged mindent: lehet módosítani a forráskódot és azt fel is lehet használni a saját alkalmazásainkban. Egyetlen feltétel van csak, kéretik megváltoztatni a névtereket, hogy egyértelmű legyen, mi az eredeti Microsoft implementáció és mi saját, illetve ami még fontosabb, ne legyen névütközés!

Az ASP.NET AJAX harmadik pillére az ASP.NET AJAX Control Toolkit, aminek a forráskódja szintén elérhető, hiszen ez nem más, mint egy közösségi projekt a CodePlexen. Ennek a kódnak a módosítása nem hogy engedélyezett, hanem szinte kívánatos, tessék beszállni a fejlesztésbe és gyártani az új, illetve javítgatni a már meglévő AJAX kontrollokat!

Hogy miért szabdalta a Microsoft három, sőt a Futures CTP-vel négy részre az Atlast? Hogy mire jók az egyes komponensek és hogyan lehet őket beépíteni a saját alkalmazásainkba? Minderről lesz szó részletesen a jövő heti MSDN Kompetenciák Egyetemén, lehet regisztrálni!

 

Technorati tags: ,
Advertisements

Amikor a bicska kinyílik a zsebben

A The New York Times január 27-én azt írta, hogy valakiknek ("group of rivals") megint nem tetszik, amit a Microsoft csinál:

The group said Microsoft’s XAML markup language — which it said was positioned to replace the current Web page language HTML — was designed “from the ground up to be dependent on Windows.”

“The very same practices the European Commission found to be illegal almost three years ago have now been implemented in Vista,” the group of rivals said.

Természetesen mindenkinek megvan a joga, hogy véleményt alkosson és eldöntse, hogy valami tetszik vagy nem tetszik neki. Sőt, hajrá, tessék csak kifejezni azt a kialakult egyéni véleményt és nem csak együtt folyni a tömeggel! Csak azt nem értem, hogy miért hőbörög valaki olyasmi miatt, aminek a hatása alól akár teljes egészében ki tudja vonni magát? Na és mi van akkor, ha egy cég valami olyat alkot, aminek köze van egy másik termékéhez? Nem kell használni egyiket sem, különösen, hogy vannak alternatívák. Ha a következő Forma 1-es szezonban a Renault kitalál egy új kormányt, ami csak a saját autóiba illik, akkor ezért fizessen büntetést a többi csapatnak vagy dobja kukába a fejlesztést?

Még soha nem hallottam, hogy a Microsoft a XAML-t szembe pozícionálta volna a HTML-lel. Ennek egyik oka valószínűleg az, hogy a HTML-től éppúgy nehéz lesz megszabadulni mint a HTTP-től vagy az IPv4-től, a másik pedig, hogy teljesen nyilvánvalóan a XAML-ben lényegesen több lehetőség van – de más területen. Ha már mindenképp a XAML-t akarjuk egy webes eszmecserébe bevonni, akkor a WPF/E lehet a mérleg másik oldalán, ami viszont megint csak teljesen nyilvánvalóan a Flash egy lehetséges alternatívája. Erre viszont már nem lehet azt mondani, hogy Windows specifikus lenne, hiszen már Mac-en is támogatott és a lista csak bővülni fog.

Az alternatívákban az a jó, hogy versenyeznek egymással. Magyarul, ha a XAML jó, hasznos, egyszerű akkor szeretni fogják a fejlesztők és megelőzi a már létező technológiákat és vezetni fog az újak előtt is. Ha pedig a XAML gagyi, akkor majd más viszi a pálmát. A versenyben pedig az a jó, hogy fejlődést eredményez, innovációt indukál, aminek egyértelműen a felhasználók, azaz mi leszünk a kedvezményezettjei.

Akkor meg mire ez a nagy felhajtás meg a "monopolista" szlogenek? Tessék alternatívát állítani a rajtvonalhoz és győzzön a jobbik!

 

Technorati tags: ,

Workflow Foundation alapozás

Véget ért a két napos Workflow Foundation Laborgyakorlat, melyet a novemberi MSDN konferenciához kapcsolódóan szerveztünk az MSDN Kompetencia Központban. Minden tanfolyam elején meg szoktam kérdezni a résztvevőket, hogy milyen a fejlesztői előéletük és hogy mit várnak ettől a tanfolyamtól. Jó volt hallani, hogy szinte mindenki ott volt a konferencián és hogy azért jöttek erre a képzésre is, mert felismerték, hogy rengeteg időt lehet azzal spórolni, hogy "több ezer oldalnyi könyv elolvasása helyett más kaparja ki a gesztenyét". Ez a hetedik év, hogy én személy szerint ebben a szellemben dolgozom, jó tudni, hogy van eredménye 🙂

Érdekes volt hallgatni mindkét nap végén, hogy ki hogyan fogalmazza meg magának a Workflow Foundation lényegét: ez nem egy rapid alkalmazásfejlesztési technológia! Ez persze elsőre csalódottságot ébreszt, de megismerve a platform alapszolgáltatásait, mindenki be tudja lőni magának, hogy mit várhat ettől a rendszertől és mit nem. A nap végén mindenki tisztába került azzal, hogy mivel jár a Workflow Foundation használata, mik az előnyei és mik lehetnek a fájdalmas pontjai. (Érdemes elolvasni Novák István első benyomásait.)

Persze sokan (én is) hajlamosak vagyunk a dolgok negatív oldalát látni, hív a sötét oldal: nehézkes a kommunikáció, kevés activity van a Base Activity Library-ben, a Visual Studioba integrálódó designer néha elhal, ráadásul rengeteget kell gépelni. Ezek tények, nem érdemes szépíteni, ez így van. Minél többet foglalkozik vele az ember, annál jobban így érzi.

De ezek mind csak elvárásaink miatt érződnek így – úgy látjuk, hogy a pohár félig üres. Ha sikerül onnan megközelítenünk a kérdést, hogy ez egy platform technológia, akkor már teljesen más lehet a kép – nézzük úgy, hogy a pohár félig tele van! Úgy vettem észre, sokan találkoztak már más workflow technológiákkal. Ha össze akarjuk hasonlítani ezeket a Workflow Foundationnel, akkor általában arra juthatunk, hogy a WF célközönsége az alkalmazásfejlesztő, a programozó, míg más technológiák gyakran másoknak készültek. Másként fogalmazva ez egy "megveszem vagy megcsinálom magamnak" kérdés. A WF nem ad adminisztrációs eszközöket, csili-vili jelentéseket, de még monitorozó alkalmazásokat sem. Ezeket mind nekünk kell megépítenünk, a platform legfeljebb API támogatást tud adni mindehhez. Megold alap problémákat és ad alap szolgáltatásokat, de semmi extra.

Újra és újra felmerül a kérdés, hogy ha ez ennyire "fapados", merjünk-e ráépíteni? A Microsoft egyértelműen ezt az irányvonalat akarja a követni, a SharePoint, a BizTalk, Speech Server, az MIIS és a Microsoft Dynamics következő verziói már biztosan ezt fogják használni. Sőt, az egyik legnépszerűbb workflow termék, a K2 is áttér Workflow Foundationre. Miért? Mert kihasználva egy stabil alaptechnológiát, képes lehet további szolgáltatásokat biztosítani a termékeiben, ami miatt érdemes lehet megvenni a K2-t.

Természetesen minél több felhasználója van egy frameworknek, annál érettebb technológiává növi ki magát. Még csak most jelent meg a .NET 3.0 és vele együtt a WF első kiadása, mégis kiváncsian várhatjuk, mi lesz a következő verzióban…

 

Technorati tags: , ,