Surface 2

Šodienas keynote sesijā konferences dalībniekus iepazīstināja ar Microsoft Research sasniegumiem. Lūk nākamā skārienjūtīgas virsmas paaudze:

Daži photo

Dažas bildes no pasākuma pieejams Picasā

From PDC2008

Windows Azure. Part 2. Service Bus

Jauka Windows Azure sastāvdaļa ir Service Bus (turpmāk - Servisu Autobuss). Tas nodrošina servisu "nogādāšanu" nepieciešamajā vietā. Pieņemsim, ka man ir serviss, kurš būtu publicējams ārpasaulei un jāpadara pieejams Mākonī. To varētu darīt divējādi: atvērt savu lokālo serveri visai pasaulei un cīnīties ar nepieciešamo drošību vai atrast pakalpojuma sniedzēju, kurš uztur Azure platformu ar Servisu Autobusu (šobrīd tāds ir tikai viens - Microsoft). Servisu autobusā es varu piereģistrēt savu servisu. Visiem klientiem, kuriem mans serviss būs nepieciešams, es iedošu tā adresi, ar norādi uz Servisu Autobusu. Tādejādi visi klientu pieprasījumi tiks maršrutizēti caur Servisu Autobusu uz manu serveri, un mans serviss būs jāpadara pieejams tikai un vienīgi manam Azure pakalpojuma sniedzējam.

Situācija patiesībā ir vēl labāka. Es varu pateikt, kuri ir autorizētie servisa lietotāji, un Servisu Autobuss, lietojot Live Identity, nodrošinās klientu autorizēšanu. Tādejādi: (1) deklaratīvi var atrisināt autorizēšanas jautājumus, (2) lietotāji var lietot savu visā webā lietoto identitāti.

Parallelism is about performance

Vienā no semināriem tika apskatīti paralēlisms un multicores aplikācijas. Mēģināšu reproducē dažas pamatidejas, par kurām pasākumā runāja.

Pamatideja: paralēlismu kodā vajadzētu ieviest tikai, kad tas ir nepieciešams, jo paralēlisms: (1) palielina kļūdu skaitu, (2) palielina sarežģītību. Tomēr rakstot kodu, vajadzētu analizēt un plānot, kurās vietās nākotnē, ja rodas kādas ātrdarbības problēmas, var ieviest paralēlismu.

Optimizējot esošu kodu, vajadzētu sekot šādos soļos:

• jāsaprot, kas tad ir lēns;
• pēc iespējas mēģināt optimizēt lēno kodu, neieviešot paralēlismu (visbiežāk ar algoritmu, atmiņas izmantošanas un IO operāciju optimizēšanu);
• identificēt vietas, kurās paralēla apstrāde ir iespējama;
• realizēt paralēlismu.

VS2010 un .Net 4.0 ir vairākas lietas, kuras palīdzēs veidot multicores aware programmas:

• Programmēšanas valodās ir iestrādātas dažādas jaunas lietas:
• pLINQ: parallel language integrated query;
• komandas: parallel.for un parallel.foreach;
• komanda: parallel.invoke {stmt1, stmt2, ....};
• task_group, kas ļaus atzīmēt komandas, kuras drīkst izpildīties paralēli, piemēram, divu atšķirīgu sarakstu sortēšana.
• VS2010 būs vairāki rīki, kuri palīdzēs analizēt sistēmas darbību, analizēt paralēlismus, identificēt savstarpējas bloķēšanās utt.

VB 10

VB 10 ir paredzēti vairāki jauninājumi, kuri pārsvarā ir saistīti ar koda rakstīšanas vienkāršošanu. Gadījumā, ja mainīgie deklarēšanas brīdī tiks inicializēti, varēs nenorādīt to datu tipus, piemēram, integer masīvu varēs deklarēt šādi:

dim iaCount = {10,20,30}

Būs pieļaujamas arī šādas konstrukcijas:

dim oArray = { 10, "kedas", 20 }

Manuprāt, tas vēl ir ļoti diskutējami, vai šādi "vienkāršojumi" ir labi :(

LINQ - vārbūt sākt lietot?

Konferences piemēros ļoti plaši tiek lietots LINQ. Faktiksi, visos gadījumos, ja no kāda saraksta vai masīva ir jātlasa ierakstu apakškopa (iespējams pat titikai viens ieraksts), tam tiek lietots LINQ. Tas izskatās ērti un patiesībā pat ļoti uzskatāmi. Turklāt tiek apgalvots, ka šādas komandas strādā ļoti efektīvi, katrā gadījumā ne sliktāk, kā pašu rakstītas pilnas pārlases.

Piemēram, lai atlasītu masīva elementus, kuri ir lielāki par 10, tiek piedāvāts šāda VB.Net komanda:

scores2 = from score in scores where score > 10 select score

Windows Azure. Part 1

Liekas, ka manas nezināšanas tuneļa galā sāk parādīties gaisma ;) Pēc pēdējo semināru apmeklējuma Azure platformas loma kļūst skaidrāka.


Microsoft mēģina izveidot platformu, kura varētu tikt lietota aplikāciju, datu u.c. izvietošanai Mākonī. Tur būtu pieejami SQL Servisi, Workflow servisi, lietotāju identificēšanas servisi u.c. Realitātē tas nozīmē, ka būs šādu servisu pakalpojumu sniedzēji, līdzīgi kā šobrīd ir webhostētāji: mums tiek piedāvāts zināms pakalpojuma serviss un saskarne tā lietošanai. To visu zinot, mēs varam veidot savas aplikācijas, izvietot pie attiecīgā servisa sniedzēja, administrēt pieejas tiesības u.c.


SQL Servisi nodrošinās datu bāzes funkcionalitāti, Worflow servisi - workflow izpildi utt. Svarīgi, ka izstrādātājam pašiem vairs nebūs jāsatraucas par savu aplikāciju pieejamību, kur tās fiziski strādā, kā skeilojas utt. Par to visu satraucas attiecīgā servisa pakalpojuma sniedzējs. Piemēram, workflow gadījumā, tas darba plūsmas kontrole notiek Tur Ārā un Tur arī tie nodrošinātās tās stāvokļa saglabāšana un nepieciešamo transakciju apkalpošana.

Lieki piebilst, ka šobrīd ir tikai viens šāda Azure servisa sniedzējs - Microsoft.