Windows iekļautās programmas lielākā daļa ir atrodamas zem C:\Windows\System32 direktorijas. Uz 32bit operētājsistēmas tur būs 32bit aplikācijas, uz 64bit operētājsistēmas – 64bit aplikācijas. Uz 64bit operētājsistēmas eksistē arī direktorija C:\Windows\SysWOW64, kurā atrodas 32bit aplikāciju versijas.

Piemēram, “calc.exe” eksistē divās versijās – 32bit versija aizņem ~750Kb, bet 64bit versija ~900Kb. Izmērs nav svarīgs, tas tikai uzskatāmi parāda, ka tas nav viens un tas pats fails.

Joki šajā sakarā sākas tad, kad 32bit aplikācija cenšas palaist, piemēram, C:\Windows\System32\calc.exe. Pat precīzi norādot direktoriju, Windows ieslēdz savu automātisko maģiju un šo ceļu pārvērš ar C:\Windows\SysWOW64\calc.exe. Tas ir, operētājsistēma izdomā, ka 32bit aplikācija taču nevarētu vēlēties palaist 64bit procesu. Saprotams, ka šāda uzvedība nodrošina labāku 32bit aplikāciju darbību uz 64bit operētājsistēmas.

Taču ne visas aplikācijas ir gan 32bit, gan 64bit versijās. Kā arī noteiktas aplikācijas apzināti var vēlēties palaist noteiktu bitu aplikāciju. Uz Windows Vista un jaunākiem ir ļoti vienkāršs un elementārs veids, kā ar šo problēmu cīnīties – C:\Windows\SysNative virtuālā direktorija.

Uzgāju sarakstu ar lapām, kur var iegūt bezmaksas e-grāmatas par dažādām programmēšanas valodām un tēmām. Sarakstā ir legālas grāmatas, kas pieejamas bez maksas, nevis zagtas versijas.

http://www.devcurry.com/2010/06/collection-of-free-programming-and.html

Lai risinātu iepriekš aprakstītās problēmas, veidojot MSSQL automātiskās rezerves kopijas, izveidoju savu mazu programmiņu. Tās galvenās funkcijas:

• veidot rezerves kopijas visām uz servera esošām datubāzēm;
• apstrādāt reizē vairākus datubāzu serverus (vai instances);
• sūtīt skaisti noformētus statusu pārskatus;
• izdzēst novecojušas rezerves kopijas.

Lejupielāde: SqlBackup.zip (gan pirmkods, gan kompilēta versija)

Konfigurācijas fails un pirmkods ir dokumentēts pietiekoši, lai jebkurš šo kodu varētu izmantot, pielāgojot vai arī neko nemainot.

Silverlight 3 iebūvētie data binding un ar to saistītās validācijas ir pamatīga sāpe. Pavisam vienkāršos scenārijos tā strādā kā gaidīts, bet pietiek vēlēties kaut ko nedaudz sarežģītāku, lai konstatētu, ka lielākā daļa vēlmju tā arī paliks vēlmes, jo tās realizēt ir praktiski neiespējami.

Labi raksti par šo tēmu atrodami The Joy Of Code blogā (trīs rakstu sērija). Par laimi, Silverlight 4 jau ir iznācis un praktisku iemeslu palikt pie Silverlight 3 īsti nav.

Agile nozīmē to, ka Izpildītājs smaida un piekrīt, kad Pasūtītājs kārtējo reizi maina tvērumu (scope).

Tāda diemžēl ir ļoti daudzu vadītāju uztvere, kas nav iemācījušies, ka kopā ar dažādām Agile metodoloģijām nenāk tikai iespēja mainīt prasības, bet arī daudz dažādi citi ierobežojumi un pasākumu kopumi. Paņem to, kas izdevīgi, nepaņemot to, kas nepieciešams, lai metodoloģiju veiksmīgi īstenotu.

Šodien ieguvu vērtīgu atziņu. Labam programmētājam ir jābūt slinkam. Labs un slinks programmētājs centīsies sev uzdoto darbu izdarīt, radot pēc iespējas mazāk artefaktus (kodu utt.). Kas savukārt nozīmē, ka radītos artefaktus vēlāk būs vieglāk pārvaldīt un uzturēt.

Jautājums gan filozofisks, bet neliela paslinkošana, pirms ķerties klāt nopietna darba izpildei, vienmēr nāks par labu, jo ļaus sakopot domas un varbūt saprast, ka pirmais izdomātais risinājums nebūt nav labākais.

Nejauši uzdūros šodien CSS funkcionalitātei, par kuru iepriekš neko nezināju. Izrādās, CSS selector-os var izmantot regulārās izteiksmes. Zemāk piemērs kā mainīt izskatu visām saitēm, kas norāda uz .pdf failiem.

Vairāk informācijas lapā, kurā par šo lietu uzzināju.

Ātrā pārbaude liecina, ka augstāk redzamais piemērs strādā uz IE7/IE8/FF3.

Kādu laiku jau nomoka doma, ka vajadzētu publicēt savus risinājumus Lattelecom IT olimpiādes uzdevumiem. Kaut vai tāpēc, lai topošajiem dalībniekiem būtu iespēja ne tikai redzēt, kādi uzdevumi bija jārisina agrāk, bet arī redzēt risinājumu piemērus, tādā veidā nedaudz izlīdzinot izredzes starp jaunajiem dalībniekiem un tiem, kas olimpiādē piedalās jau otro vai trešo gadu pēc kārtas.

Kā pirmo šādu piemēru izvēlējos 2009. gada fināla kārtas studentu grupas 1. dienas uzdevumu “S: SMTP/POP3 serveris”. Šāds uzdevums tika izvēlēts, jo SMTP un POP3 protokoli, lai arī mūžseni, ir vēl joprojām ļoti aktuāli, bet tajā pašā laikā ļoti triviāli, ja nav mērķis saprast e-pasta saturu, bet tikai to pārsūtīt tālāk.

Pirmais solis, šo uzdevumu pildot, ir atrast protokola aprakstus. Pirmā iespaida iegūšanai nekā labāka par Wikipedia nevar vēlēties – SMTP un POP3. Tālāk jau var pētīt precīzās specifikācijas, kurās būtu jābūt aprakstītām visām detaļām: RFC 5321 (SMTP) un RFC 1939 (POP3). Un, pats galvenais, jāver vaļā komandrinda un telnet, lai izmēģinātu ar roku pieslēgties kādam reālam serverim.

IT olimpiādē dalībniekiem bija 6,5 stundas, lai ar šo uzdevumu tiktu galā. Diemžēl tikai viena komanda (Tornado) iesniedza risinājumu, kas veiksmīgi tika galā ar e-pastu saņemšanu un atdošanu klienta programmatūrai. Tā kā man pašam ir acīmredzamas priekšrocības, kas radās, pašam izdomājot šo uzdevumu, risinājums tādā formā, kā tas redzams pievienotajā arhīvā, aizņēma apmēram 2,5 līdz 3 stundas.

SimpleMail risinājums: SimpleMail.zip  (44kb). Risinājums gan netiek darbināts kā serviss, bet gan kā komandrindas aplikācija, taču tas darīts, lai vienkāršotu tā izmēģināšanu. Tāpat nav arī realizētas papildus iespējas, par kurām olimpiādē vienojās dalībnieki. Tornado komandas risinājumā vairākas papildus iespējas bija realizētas.

Kā darbināt serveri – jāpalaiž SimpleMail.exe un sava klienta programmatūra jākonfigurē, lai izmantotu 127.0.0.1:25 un 127.0.0.1:110. Jāņem vērā, ka localhost vārda izmantošana varētu nestrādāt, ja e-pasta programmatūra atbalsta IPv6 – tādā gadījumā tā mēģinās slēgties pie adreses ::1, kuru serveris var neatbalstīt. Serveris pieņem e-pastus visiem adresātiem, lai piekļūtu pie saņemtajām e-pasta adresēm, kā POP3 lietotāja vārds un parole jānorāda šī e-pasta adrese.

Risinājumā ir ļoti daudz punktu, kurus vajadzētu pielabot, taču galveno virzienu, kādā strādāt, tas labi parāda.

Pamata servera darbību nodrošina klase BaseServer. Izveidojot šo objektu, tas automātiski palaiž TCP serveri (izmantojot TcpListener klasi) un jaunu pavedienu (Thread), kurš gaidīs, kad pie servera kāds pieslēgsies. Svarīga nianse – šis pavediens pats jauno pieslēgumu neapstrādā. Tā vietā tas izmanto metodi QueueUserWorkItem, kas nodrošina spēju apstrādāt vairākus pieslēgumus reizē. QueueUserWorkItem izmanto .NET iebūvētu slodzes dalīšanas mehānismu, kas ļauj reģistrēt vairākas darba vienības, kuras tiek izpildītas viena pēc otras, nodrošinot, ka paralēli netiek izpildīti vairāk uzdevumu kā dators spēj veiksmīgi darbināt.

BaseServer nodrošina pamata funkcionalitāti – tas no pieslēguma nolasa komandu (gan SMTP, gan POP3 komanda tiek nodota vienā atsevišķā teksta rindā) un nodod šo komandu apstrādei IProcessor interfeisam. Klases, kas implementē šo interfeisu (SmtpProcessor un Pop3Processor), nodrošina katras konkrētas komandas izpildi, kā arī saglabā pieslēguma stāvokļa informāciju (lietotāja vārdi, e-pasta saņēmēji utt.).

Šādi sadalīts kods ļauj izvairīties no koda dublēšanas un nodalīt tīkla savienojuma apstrādi no SMTP vai POP3 komandu apstrādes. Izmantotais mehānisms arī demonstrē salīdzinoši elegantu veidu, kā nodrošināt salīdzinoši augstu veiktspēju, kur viens pieslēgums nebloķē citus.

Diemžēl sastapta kārtējā problēma ASP.NET iekšienē, kam būtu jābūt ļoti plaši izplatītai, tik nez kāpēc Microsoft nav uzskatījis par vajadzīgu to labot. Arī Connect sistēmā neatrodu, ka kas līdzīgs ir reģistrēts (būs jāpacenšas, taču nedomāju, ka tas ko mainīs).

Lai problēmu atkārtotu, var izveidot šādu lapu:

Problēma attiecas ne tikai uz ASP.NET Ajax, bet arī uz parastu ASP.NET lapu bez ScriptManager un UpdatePanel, taču tad tā parasti nav pamanāma, ja vien lapas apstrādē ir kaut neliela aizture.

Ja izmaina teksta lauka vērtību, tā tiek automātiski nosūtīta uz serveri un tas atgriež vērtību “textbox”. Savukārt, ja tiek nospiests uz pogas, tad serveris atgriež vērtību “submit”. Problēma slēpjas apstāklī, ka lietotājs, izmainot teksta lauka vērtību un uzreiz spiežot uz pogas, sagaida, ka tiks apstrādāta pogas nospiešana (piemēram, saglabāti dati). Šī brīža ASP.NET implementācijā tā nenotiek – uz serveri tiek nosūtīts AutoPostBack pieprasījums, bet lietotāja nospiestā poga paliek bez efekta. Ir pat tā, ka uz serveri reizēm var tikt nosūtīti abi divi, taču lietotājs redz, ka izpildās tikai viens.

Piedāvāju savu risinājumu (apkārtceļu) šai problēmai. Tam ir vairāki mīnusi, piemēram, ja no teksta lauka iziet ar Tab taustiņa palīdzību, uzreiz nonākot uz pogas, tad AutoPostBack nenostrādās (lai gan reāli uz pogas nospiests netiek). Tāpat to var apiet, nospiežot uz pogas un tad nobīdot peli nost, lai pogas klikšķis nenostrādā.

Dotais JavaScript kods (jāievieto lapas beigās) aizvieto ASP.NET iebūvēto __doPostBack metodi, kas tiek izsaukta AutoPostBack gadījumā. Jaunā funkcija pārbauda, vai lietotājs nav nofokusējies uz kādu pogu un, ja tā ir, atceļ AutoPostBack pieprasījumu. Diemžēl tas nav ideāls risinājums, bet šobrīd vienīgais, kas lietotāju glābj no nepatīkamas situācijas, kur viņš ir nospiedis saglabāšanas pogu, bet reāli nekas saglabāts netiek.

Nekad neesmu tā īsti programmējis Javā, jo vienkārši nav bijusi tāda vajadzība. Tomēr ik pa laikam uzduros kādam piemēram, kas man liek atviegloti uzelpot, ka strādāju .NET-ā ar C# un nevis, izmantojot Java.

Javā ir klase Long. C# analogs būtu Nullable<System.Int64> vai long?. Tātad – vērtība var būt vai nu 64bit skaitlis vai arī null. Dokumentācija.

Tik tālu viss būtu labi. Bet... Javā ir arī primitīvais tips long. C# analogs ir System.Int64 vai long. Vērtība var būt 64bit skaitlis, null vērtību piešķirt nevar.

C# valodā atšķirība ir vai nu System.Nullable<> pieraksts vai arī jautājuma zīmes simbols.

Java valodā atšķirība ir lielais/mazais burts.

Es, protams, saprotu, ka jebkuram Java programmētājam šī ir absolūti pašsaprotama lieta, bet man kā skatītājam no malas tas šķiet absolūti idiotisks lēmums valodas veidošanas procesā. Kas rezultējas vairākās stundās, kas pavadītas, meklējot kļūdu.

Ieskatam neliels raksts par to, kā .NET frontē notiek lēmumu pieņemšana: Building Tuple.