“Uz dullo”

Nesen gadījās izmantot dr.Viļņa Detlova lietoto izlozes metodi un te ir tās īss apraksts.

Dots

  • n elementu saraksts, no kura uz labu laimi jāizlozē viens ieraksts (piemēram, 25 cilvēku vārdi)
  • viens vai vairāki subjektīvi gadījuma skaitļu ģeneratori (piemēram, 2 cilvēki)
  • kalkulators (vēlami)

Izloze

  • sanumurē apskatāmā saraksta rindiņas sākot ar 0 un beidzot ar n-1
  • katrs skaitļu ģenerators iedomājas un paziņo citiem skaitli, kas par pārsniedz n (piemēram, viens dalībnieks paziņo skaitli 4842, otrs – 9222)
  • sasummē iegūto skaitļu kvadrātus, iegūstot kopīgu gadījuma lielumu K (K=48421^2+922103^2= 23444964+85045284= 108490248)
    • aprēķina (K mod n) un iegūst uzvarētāja kārtas numuru (108490248 mod 25 == 23, tātad uzvar priekšpēdējais dalībnieks)

Risinājuma pamatojums

  • Visiem saraksta elementiem ir līdzīga laba varbūtība kļūt par uzvarētājiem (neesmu mēģinājis pierādīt, bet šķiet labāka nekā ja mēģinātu izvēlēties skaitli no 0 līdz n-1)
  • Rezultāta izvēlē var iesaistīties pēc patikas daudz dalībnieku
  • Tā kā sākotnēji katrs dalībnieks nezina citu izvēlētos skaitļus, tas nevar iespaidot rezultātu ar subjektīvi izvēlētu gadījuma vērtību
  • Pat ja pēdējais dalībnieks redz iepriekšējo izvēlētos skaitļus, subjektīvi izvēlēta gadījuma skaitļa aprēķināšana ir apgrūtināta, jo skaitļi tiek kāpināti kvadrātā, tādēļ “prātā” jādarbojas ar nepatīkami lieliem skaitļiem.

Ko pasaule zina par Storm Worm?

Ievadam – apnika lasīt par jauniem gadždetiem. Jāuzlabo LV blogu kultūra reportējot arī par citiem jaunumiem.

IEEE izdotā žurnāla “Computerfebruāra numurā ir ļoti interesants raksts par Storm Worm. IEEE bibliotēkas lasītājiem šis raksts ir pieejams arī tiešsaistē: “A Storm (Worm) Is Brewing”.

Īsumā – kopš 2006. gada rudens IT drošības pasaule ir iepazinusi jaunu ienaidnieku, kurš ticis pie vārda Storm, pirmo reizi īsti par sevi liekot manīt 2007. gada 19. janvārī, kad dienas laikā tika izsūtīts apmēram 20 reižu lielāks surogātpasta daudzums nekā citās dienās. Citi šī ienaidnieka nosaukumi ir Nuwar, Peacomm, Zhelatin. Pēdējais nosaukums vislabāk parāda šī kiber-ienaidnieka dabu, jo tieši mainīguma dēļ IT drošības kompānijām ir tik grūti izstrādāt pretlīdzekļus Storm-am.

Storm ir milzīgs attālināti kontrolējamu (“zombiju“) datoru tīkls, ar kura palīdzību tiek veikti kibernoziegumi, vienlaicīgi arī inficējot jaunus datorus un tos piesaistot storm tīklam. Drošības ekspertiem ir izdevies noteikt, ka tīkla darbības kontrolei tiek izmantoti austrumeiropā (tātad – arī Latvijā?) un Krievijā esošas IP adreses. Krievijas valdība atsakās sadarboties ar ASV spēkiem, lai likvidētu Storm tīklu.

Ir izteikti minējumi, ka 2007. gada pavasara DDoS uzbrukumi Igaunijas serveriem tikuši veikti no Storm tīkla. Tāpat Storm tiek pielietots naudas pelnīšanai, izsūtot surogātpastu, kas reklamē organizācijas, kuru akcijas pieder Storm īpašniekiem. Joe Stewart, SecureWorks pētnieks norāda, ka pastāv aizdomas, ka kāda Kanādas kompānija savulaik izīrējusi daļu tīkla resursu, lai izsūtītu surogātpastu.

Daži fakti par Storm:

  • Izplatās, izmantojot sociālās inženierijas ceļus. Izsūta e-pasta vēstules, ar tēmām “Milzīga vētra Eiropā”, “Nogalinājis 11 gados, 21 gada vecumā atkal brīvs un dodas nogalināt”, “Britu genocīds pret musulmaņiem”, “Krievu raķete notriekusi ASV satelītu”. Tāpat tiek izsūtītas e-pasta vēstules, kas satur saiti uz it kā Youtube esošām filmām. Vēl vienu klikšķi tālāk lietotāja neprasmīgi aizsargātais dators tiek inficēts ar Trojas zirgu.
  • Pēc datora inficēšanas sistēma var uzstādīt klaviatūras signālu pārķeršanas draiverus un šo informāciju pārsūtīt tīkla īpašniekiem. Protams, tiek izveidota “lūka”, caur kuru Storm īpašnieki var nodot komandas datoram
  • Programmatūra slēpjas. Tā instalē rootkit-us, lai izpildāmie faili nebūtu redzami datora lietotājam, tā modificē API, kas parāda aktīvos procesus, tā dzēš rīkus, kas ļautu identificēt Storm klātesamību.
  • Inficētie datori uzvedas gluži normāli un ir lietojami ikdienas darbam.
  • Decentralizēts – savstarpējai saziņai un izplatīšanai izmanto P2P tīklus, izmantojot savus protokolus un arī standarta rīkus kā ICQ un IRC
  • Izmanto t.s. fast flux principu, lai paslēptu web vietnes, kas satur inficējošo kodu. DNS ieraksti tiek mainīti ik pa dažām minūtēm, kas sevišķi apgrūtina izsekošanu.
  • Izplatīšanai vienlaicīgi izmanto tikai nelielu daļu no tīklā esošajiem datoriem, bet šī daļa regulāri mainās
  • Šifrē visu saziņu starp tīklā esošajiem datoriem, izmantojot vismaz 40 bitu atslēgas (simetriskās kriptosistēmās tas ir pietiekami daudz)
  • Izplatīšanās mehānisms tiek regulāri mainīts, tai skaitā mainot arī modificējot izpildāmo kodu līdz pat 10 reizēm stundā

UTF8 adreses

Lietojot wikipediju, vienmēr meklēto vārdu rakstu uzreiz adresē (http://en.wikipedia.org/wiki/<vajadzīgais vārds>).

Līdzīgu pieeju mēģināju lietot arī latviešu wikipēdijā, bet secināju, ka vārdos ar latviešu diakritiskajiem simboliem tas nedarbojas. Piemēram, mēģinot atrast skaidrojumu vārdam “Māra”, atveras lapa “Mâra” (kur, protams, nekāda satura nav).

Kā noskaidroju, Firefox lietotāji to var labot ar slēdža Network.standard-url.encode-utf8 palīdzību. Uzstādot šo slēdzi uz “true”, Firefox sāk darboties atbilstoši RFC 3987 un visi nestandarta burti tiek kodēti ar URLencode.

Tas gan man nedarīja saprotamu, kāpēc pirmajā gadījumā teksts nokodējās uz
http://lv.wikipedia.org/wiki/M%C3%A2ra (Mâra)
bet otrajā uz
http://lv.wikipedia.org/wiki/M%C4%81ra (Māra)

Upd: Izskatās, ka šeit aprakstītā problēma nepastāv citos datoros kā tikai man mājās pieejamajos.

Tulkošanas makrosi

Divi Word makrosi, kas varētu noderēt tiem, kam nav instalēta Tildes vārdnīca, bet ir pieejams internets.

Lai lietotu, makrosu projektiem referencēs jāpieliek Microsoft XML (es liku V 6.0, bet derēs jebkurš). Pēc tam atliek uzbindēt klaviatūras saīsni. Piemēram, es ieliku Shift+Ctrl+Alt+E tulkojumam uz angļu valodu un Shift+Ctrl+Alt+L tulkojumam uz latviešu valodu. Pēc tam, kad vajag tulkojumu, iezīmējam tulkojamo vārdu un izpildām klaviatūras maģiju.

Uzskatu, ka SIA “Tilde” tiesības ar šo neesmu pārkāpis, jo esmu tikai vienkāršojis piekļuvi datiem, kas ir publiski pieejami.

Rezultāts izskatās šādi:

translator.png

Continue reading Tulkošanas makrosi

Sharepoint – LOC?

This is rather a question or an idea for a discussion than a regular blog post.

I’m just wondering how does one count LOC in Sharepoint? Or, to be more general, how do you measure the amount of work that has been invested in creating a solution in Sharepoint.

A solution can consist of

  • content type definitions (XML files),
  • list definitions (XML files again)
  • feature definitions (XML),
  • Solution manifests (XML),
  • CAB file descriptors (“code”),
  • ASPX pages (ASP.net code),
  • ASPX code-behind files (finally, VB.net, countable!),
  • Event handlers code (VB.net, cool),
  • Workflow diagrams (generated VB.net code),
  • Workflow code-behind files (VB.Net files),
  • Workflow rules (XML),
  • … and many more things which are not crurrently the case for me;-)

So how do you put it all together? In my opinion, a line in feature.xml file has much more value than a table-tr-td line in ASPX page (the former can break “everything” in your site while the latter cannot). Some lines in list definitions are valuable, some are not. Should one assign values to LOCs of each file type? Seems like LOC is no answer at all. For instance, workflow designer generated code has kind of “no value” as a VB.Net code and LOC measurement wouldn’t tell you much about the effort made to create the particular workflow.

“Ja nu” failu nosaukumos

Vienmēr gribas būt drošiem, ka automātiski pieglabāto failu nosaukumi būs failsistēmai saprotami. Neliels “tīrītājs”, kas izvāc visādus #, \, / utt liekos simbolus. Uzticamies latviešu burtiem, atstarpēm neuzticamies vis.

Public Function GetGoodFileName(ByVal spText As String) As String
    Return System.Text.RegularExpressions.Regex.Replace(spText, _
            "[^a-zA-Z0-9āčēģīķļņšūžĀČĒĢĪĶĻŅŠŪŽ_-]", "")
End Function

Sharepoint Workflow modificēšanas formas izveide ar InfoPath

Iesākumam

Workflow modificēšanas formas jāveido kā InfoPath XSN formas, nevis kā ASPX formas. InfoPath ir dabūjams pilnajā MSOffice paketē, oficiāli tas piederas pie “Microsoft Office Suites and Applications 2007” pakas

Pašas formas izveide

Jāveido jauna forma, to veidojot uzreiz vēlams uzstādīt ķeksi “hide features that do not work in InfoPath Forms Services” (saucas kaut kā citādi, bet ideja ir tā).

Svarīgi ir uzlikt sekojošus atribūtus iekš “Tools->Form options”:

Browser
  • Izvācam ķeķšus pie “Show toolbar at top of form; show toolbar at bottom of form.
    Modifikācijas formā šie toolbari nav būtiski, jo formas submitošanai visticamāk izmantosim pogu. Savukārt “Save”, “Update” utt darbības vispār šeit ir liekas.
Security and trust
  • Security level: Domain (neļaujam automātiski noteikt)
  • Security and trust -> Sign this form template. Ja ir administratoru piešķirts sertifikāts, var parakstīt ar to, bet šīm vajadzībām pietiek arī ar “Create certificate” (pats priekš sevis izveidos sertifikātu)
Compatibility
  • Design a form template that can be opened in a browser or InfoPath

Datu submitēšanai jāizveido datu konekcija, kas nodos atpakaļ informāciju uz “hosting environment” (mūsu gadījumā – sharepoint workflow-am). To dara zem Tools->Data Connections. Jāspiež “Add”, jāizvēlas “Create new connection to: Submit data”. Nākamajā logā – “To the hosting environment…” un jāiedod konekcijai vārds.

Tai pogai, kas būs kā “submit” attiecīgi jāiekonfigurē, ka vai nu:

  • tā ir submit poga – tad prasīs, pa kuru datu konekciju sazināties ar formu. Tad jāuzstāda, ka pie submitēšanas lietotājam nerāda paziņojumu, ka submits ir veiksmīgs un pēc submitēšanas aizver formu
  • tā ir parasta poga, kas darbojas uz likumu (rules) pamata. Tad jāizveido likums, kas uzstāda formas vērtības un beigās nosubmitē formu un to aizver

Formas datu shēmai būtu vēlams iedot sakarīgu nosaukumu, pēc noklusējuma tas ir “myFields” – ja negribam ar tādu turpmāk strādāt, jāpārsauc un jāizveido normāli.

Kad viss gatavs, dodamies File->Publish. * Izvēlamies “To a network location”. Norādām vietu uz c:, kur vēlamies formu “publicēt”, norādām formas nosaukumu vai, ja apmierina piedāvātais, atstājam to pašu. * Pēc tam wizardā ir jautājums “If all form users can access the location that you entered in the previous step, Click next”. Šeit ir svarīgi atstāt to teksta lauku TUKŠU, citādi forma nestrādās worklfowā! * Izmetīs warningu, ka tas var būt slikti – spiežam OK.

Paņemam File->Properties un apskatāmies/nokopējam automātiski noģenerēto “ID” lauka vērtību, kas izskatās apmēram kā “urn:schemas-microsoft-com:office:infopath:ReviewModForm:-myXSD-2007-08-22T06-32-52”

Formas lietošana worklfowā

Lai formu piesaistītu workflovam, kas aprakstīts kā Sharepoint Feature.

Iekopējam publicēto XSN failu blakus feature.xml failam. Instalējot featuri, šim XSN jānokļūst zem c:\program files….\12\template\features\ManaFeature

Feature.XML:
  • Feature tagā:
    svarīgas ir šādas rindas (<Feature> taga iekšpusē, To rezultātā, pie feature aktivizēšanas, izpildīsies kods, kas aktivizē arī workflow-am piesaistītās formas):
    ReceiverAssembly=”Microsoft.Office.Workflow.Feature, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c” ReceiverClass=”Microsoft.Office.Workflow.Feature.WorkflowFeatureReceiver”

  • ElementManifests tagā:
    Visi XSN faili jāpiemin arī ElementManifests tagā. Manā gadījumā bija:
    <ElementFile Location=”ReviewModForm.xsn”/>

  • Properties tagā:
    Lai tiktu aktivizētas šīs formas, papildus vēl arī <Properties> tagā jāieliek šāda rinda:
    <Property Key=”RegisterForms” Value=”*.xsn” />

Workflow.xml (vai kā nu saucas XMLs, kas apraksta workflowu:
  • Workflow tagā:
    Uztādām noklusēto WorkflowModifications:
    ModificationUrl=”_layouts/ModWrkflIP.aspx”

  • MetaData tagā:
    Jāveido jauns modifikācijas apraksts, kas atsaucas uz formu. Manā gadījumā bija:
    <Modification_d03867f5-99f7-469e-94af-7fcefe476a22_FormURN>
    urn:schemas-microsoft-com:office:infopath:ReviewModForm:-myXSD-2007-08-22T06-32-52
    </Modification_d03867f5-99f7-469e-94af-7fcefe476a22_FormURN>
    <Modification_d03867f5-99f7-469e-94af-7fcefe476a22_Name>
    Atsaukt saskaņošanu
    </Modification_d03867f5-99f7-469e-94af-7fcefe476a22_Name>

Ar slīprakstu atzīmēju tās vietas, kas katram gadījumam ir citādi. Kā redzams, šeit FormURN tagā iekšpusē esošais sakrīt ar to formas ID, kas tika nokopēts InfoPath-ā. Jaunu GUID ģenerējam ar GuidGen, UZMANĪGI – tam guidgen uzģenerēs ar lielajiem burtiem. VisualStudio izmantojot, tas automātiski pārtaisa uz mazajiem burtiem. Tāpēc ērtāk būs arī šeit izmantot ar mazajiem, jo citādi tas netiks atpazīts.

Pašā workflowā, vietā, kur šāda modifikācija ir pieļaujama, jāievieto EnableModification aktivitāte, kurai ModificationID uzstāda uz iepriekšējā solī ģenerēto GUIDu (ar mazajiem burtiem). Pēc tam vēlams ieveitot “EventHandlingScope”, kur normālajā zarā veic normālo darbu, bet eventu ķērājā ieliek EventDriven aktivitāti, kas gaida OnWorkflowModified notikumu (šeit atkal sasaiste notiek pēc ModificationID).

Šajā brīdī vēl nekas nestrādās, jo nav izveidota datu apmaiņa starp InfoPath formu un Workflow. No WF puses tā tiek nodrošināta, izmantojot ContextData atribūtu – tur tiek sagaidīts XMLs kas atbilst InfoPath formas aprakstītajai shēmai. Tieši tādu pašu ContextData piedāvā arī OnWorkflowModified aktivitāte, tikai šeit saņemam no formas atpakaļ pienākušos datus.

XMLu, protams, var sacerēt pats, bet var arī iegūt automātiski.

XSD shēmas ģenerēšana

InfoPath formu atveram dizainēšanas režīmā, izvēlamies tai “Save as Source files” un izvēlas, kur saglabās. Izvēlētajā folderī uzradīsies vairāki faili, no kuriem svarīgākais: myschema.xsd – tas satur mūsu InfoPath formas shēmu.

Pēc tam no šīs shēmas var uzģenerēt VB vai C# klasi, kas “apkalpo” šādu shēmu. To darām ar komandrindas rīku “xsd.exe”:

  cd c:\manataka
  xsd.exe myschema.xsd /C /o:.\ /L:VB

Uzģenerējas fails myschema.vb, kurā iekšā klase ar nosaukumu tādu, kā iedevām savam datasetam 1. solī. Manā gadījumā – ReviewModDataSet

Šo klases failu iekļaujam savā projektā. Lai sagatavotu aktivitātei nepieciešamo XML stringu, var lietot šādu koda fragmentu:

        Dim oFormData As New ReviewModDataSet
        Using stream As New IO.MemoryStream
            Dim serializer As New Xml.Serialization.XmlSerializer(GetType(ReviewModDataSet))
            serializer.Serialize(stream, oFormData)
            Me.enableRecall_ContextData = Encoding.UTF8.GetString(stream.GetBuffer())
        End Using

Ar slīprakstu iezīmēju atribūtu, kurā nepieciešams uzstādīt iegūto XML vērtību.

Sharepoint un yyyy.MM.dd

Kad uzinstalēsiet Sharepoint valodu paku, par kuru rakstīju iepriekšējā ierakstā un gribēsiet, lai “viss būtu pavisam latviski”, var gadīties vilties tāpat kā man.

SPPS ļauj glīti nomainīt gan “Sort order”, gan “Locale” katram atsevišķam Web vai Site objektam. To dara apmēram šādi. Varam uzstādīt latviešu lokāli un latviešu kārtošanas secību. Rezultātā iegūstam, ka konkrētā vietne tiešām izmanto 1062 lokāli (&H426 vai lv-LV, var saukt dažādi).

Pēc vērtības nomainīšanas, varam, skatot kādu ierakstu, pamanīt: “Izveidots: 2007.07.31 , 11:30. Autors: TādsUnTāds”.
Rodas jautājums, kas gan tas par interesantu datuma formātu, kurā sākumā raksta gadu, tad mēnesi un tad datumu (yyyy.MM.dd.) Skolā taču mums ir mācīts izmantot formātu dd.MM.yyyy, tātad šodien es gribētu rakstīt 31.07.2007.

Pēc nelādzīgi plašas izpētes esmu noskaidrojis, ka tā tas ir paredzēts! Microsoft darinātais (bet acīmredzot taču kādas latviešu komisijas ieteiktais) formāts ir tieši tāds.

Neliels VB.Net koda fragments parāda, ka tā ir:

    Dim oLoc As New Globalization.CultureInfo( _ 
                    culture:=1062, _ 
                    useUserOverride:=False)
    Debug.WriteLine(oLoc.Name & ": " & _
                    oLoc.DisplayName & ":" & _
                    oLoc.DateTimeFormat.ShortDatePattern)

Izejā tiek izdrukāts

   lv-LV: Latvian (Latvia):yyyy.MM.dd.

Sharepoint to ņem vērā un tieši tā arī parāda datumus. Kāpēc mēs to ikdienā neredzam? Visticamāk, tāpēc, ka vai nu paši vai sistēmu administratori pēc operētājsistēmas instalēšanas esam atvēruši Control Panel un nomainījuši datuma formātu sadaļā “Regional Settings”. Koda piemērā bija redzams, ka parametrs “useUserOverride” tiek nodots kā “False”, tātad – ignorējot lietotāja veiktos pielāgojumus. Protams, savā datorā veicot pārbaudi un šo parametru norādot kā “True”, ieraudzīju jau sagaidāmo datuma formātu.

Sharepoint, kas ir servera produkts, nedrīkstētu izmantot atsevišķa lietotāja veiktus pielāgojumus, lai rādītu saturu citiem lietotājiem – un tā tas arī dara.

Pašlaik diemžēl neredzu labu apkārtceļu. Vienkāršākais ir uzstādīt, ka izmantosim vācu lokāli (1032), bet tad vietās, kur uz ekrāna parādās garais datums, parādīsies “Diensdag, 31. Juli”.

Sharepoint runā latviski

Šodien (31.07.2007) ir nopublicēta latviešu valodas paka, kas paredzēta Microsoft Office Sharepoint Server. Tā pieejama Microsoft lejupielāžu centrā “par velti”, tas ir, licencēšanas noteikumi tie paši vecie. Ļoti ceru, ka tulkojums būs pilnīgs un bez īpaši pamanāmām kļūdām.
Lejupielāde: MOSS2007 valodu paka.

Ja nepieciešama valodu paka “plikajam” Windows Sharepoint Services, tā pieejama jau ilgāku laiku.Te gan uzreiz gribu brīdināt, ka šis latviskojums ir nepilnīgs. Publiskajā daļā redzamie teksti ir nolatviskoti, administrācijas daļā vietām redzami arī angliski teksti, vietām vispār parādās resursu identifikatori (izskatās apmēram kā $Resources:UberAdminLink$).
Lejupielāde: WSS 3.0 valodu paka