Vienīgais sakarīgais iemesls, kuru es varētu pieņemt kā ieganstu (D)VCS nelietošanai, ir slinkums. Tas ir cilvēcīgi saprotami :)

Es par savām vajadzībām izcilu esmu atzinis Git. Neba nu citas ir sliktākas. Piemēram, Mercurial vairākos aspektos ar lietām tiek galā labāk nekā Git. Esmu dzirdējis arī par Darcs un Bazaar, tomēr esmu lepns Git lietotājs. Jāpiebilst, ka par labu šai izvēlei savu lomu ir nospēlējis arī GitHub projekts.

Vēlētos piespiest sevi uzrakstīt rakstu sēriju, kurā saviem vārdiem mazliet apskaidrot – kas un kā. Pasmelties idejas un pieredzi no jums. Tāpēc arī rakstu. Un sākšu ar pamatu. Tiem, kas labprāt lasa angliski un steidzās, nāksies meklēt citur. Piemēram, lasot grāmatas internetos. Viena no visieteicamākajām grāmatām ir Pro Git. Protams, ka nebūt ne slikta ir tautas rakstītā grāmatiņa: Git Community Book. Pieminēšanas vērts ir arī projekts Git Magic, kas ir ieturēts mazliet … savādākā stilā. Protams, ka atceramies Git Reference. Jo sevišķi dēļ viegli atminamās adreses (gitref.org) un saprātīga vizuālā noformējuma.

Git ir sadalīta (distributed) versiju kontroles sistēma. Tai nav nepieciešams serveris. Tas nozīmē, ka jebkurš var uzinstalēt atbilstošu programmu, un sākt veidot un kontrolēt savas versijas. Momentā. Papildus tam, vēlētos piebilst, ka parasti Git mācās divos piegājienos. Pirmais – pamatfunkcionalitāte, kura piemīt jekburai ierastajai versiju kontroles sistēmai. Tas ir vienkārši saprotams un apgūstams. Nākamais jau ir tas, kur ir Git (jā, arī citu (D)VCS, trolli!) lielais spēks. Pats fundamentu fundaments: zarošana (branches), pati distributed komponente, indekss jeb staging area, utt.

Bet, pirms sākt, vajadzētu iepazīties ar galvenajiem konceptiem. Jā, zinu, ka tas ir pilnīgs bōrings, un dajoš mums reāli noderīgu un praksē pielietojamu infu, taču, taču pacietību, lūdzu. Viss būs.

Repository. Latviskojot sanāk kaut kas līdzīgs glabātavai vai krātuvei. Vai kapličai. Krātuve (izvēlējos šo) ir vieta, kurā satiekas visi tavi komiti (no commit, kas, diemžēl, tulkojas kā nodevums:). Git neglabā neiedomājamu skaitu modificēto failu versijas, bet gan tikai izmaiņas. Un, atšķirībā no CVS, tas visu glabā vienā vietā, nevis katrā apakšdirektorijā veidojot kaut ko savu. Krātuve satur, protams, arī metadatus, kas ietver sevī zarus (branches) un birkas (tags), kā arī vēl visvisādu informāciju, kas pašlaik varbūt pat nav tik dikti būtiska.

Commit (sauksim to par komitu; ejiet ieskrieties, pūristi). Versiju kontroles sistēmas pamatu pamats. Bez komita nebūtu versiju un nebūtu kontroles. Komits Git izpratnē ir versiju kontrolē iekļauto failu stāvoklis konkrētajā brīdī. Tas ir kā daudziem tik ļoti ierastās mapes manalapa.2011.07.01 un manalapa.2010.01.01. Taču, kā jau minēju, neaizņem tik daudz vietas, jo Git saglabā tikai izmaiņas kopš iepriekšējā reģistrētā stāvokļa (komita). Lai arī gribētos domāt, ka jebkurš iepriekšējais komits norāda uz nākamo, patiesībā ir otrādāk. Jebkurš nākamais komits norāda uz vienu vai vairākiem iepriekšējiem. Tā ir būtiska nianse, kas jāzin.

Working tree (darba versija?) ir tā augstākā līmeņa direktorija, ar kuru ir saistīta krātuve. Piemēram, ja mēs kontrolējam versijas iekš /var/www/manalapa, tad tā arī ir darba versija. Darba nozīmē, ka ar šo direktoriju mēs fiziski strādājam.

Staging area jeb indekss ir vieta, kur nonāk izmaiņas pēc to rašanās, bet pirms komitēšanas. Šis ir koncepts, kurš nepastāv ierastajās VCS. Ideja ir tāda, ka jebkurš komits ņem izmaiņas no staging area. Tas nozīmē, ka ir iespējama daudz detalizētāka kontrole pār to, kas tiek komitots. To var salīdzināt ar izmaiņu apstiprināšanu, pirms komitošanas – lai izmaiņas apstiprinātu, ir jāizmanto koamnda git add. No šī var izvairīties ar git commit -a, taču tas nāks vēlāk. Starp citu, ToirtoiseGit sekmīgi slēpj staging area koncepciju aiz savas vienkāršības.

Branch jeb atzars. Lai arī citās versiju kontroles sistēmās šī padarīšana ir pastāvējusi, tieši Git to ir izvedis, ja tā var izteikties, tautās, jo pārslēgšanša starp atzariem pat lieliem projektiem notiek ātri (jā, es vakar paprovēju nosvičot branču 2GB+ SVN projektam…). Atzari ir DVCS izstrādes cikla pašā pamatā. Ar šo Git principā vienpersoniski nogalināja visas tradicionālās VCS. Tīri tehniski atzars ir primitīva norāde uz kādu no komitiem. Teorijā, savukārt, viss ir daudz smalkāk. Atzari palīdz paralēli uzturēt neierobežotu skaitu versiju – izstrādes versija, produkcijas versija, ūber-fīča-X. Tie visi ir atzari, kas savā starpā var tikt apvienoti pilnīgi vai daļēji.

Tag jeb birka. Komitam piekabināms nosaukums. Piemēram, v1.0 :)

HEAD. Tā ir norāde uz faktisko izčekoto komitu vai atzaru. Izčekot komitu vai atzaru mēs varam mūsdienīgi aprakstīt kā Klau, zini, kā man vakar izskatījās kods? Izčekosim un iečekosim, ne?. HEAD vienmēr norādīs uz to, ar ko tiek strādāts no vēstures viedokļa. Par izčekošanu vēlāk, protams.

Šķiet, ka ar šo vajadzētu pietikt. Daudzi (ja ne visi) lielie palagi par Git sāk ar failu uzbūves, iekšējo struktūru un cita krepa aprakstīšanu, kas visus pamatā arī atbaida. Es centīšos no tā izvairīties, bet augstāk uzskaitītie koncepti tik tiešām ir fundamentāli nepieciešami.

Tā kā es nepretendēju uz 100% pareizību, jo neesmu nekāds guru, tad labojumi gaidāmi komentāros. Neprecizitātes ierakstā apsolos labot ar atsaucēm uz komentāriem. Tas pats attiecas uz izmantotajiem latviskojumiem – ja tev ir svaiga ideja, kas ģeldēs, dod ziņu. Pēc gada tiksimies otrajā sērijas ierakstā :)

MySQL ir milzums konfigurācijas parametru, ar kuru palīdzību atkarībā no servera izmantošanas veida var panākt milzīgu ātrdarbības pieaugumu. It sevišķi tas attiecas uz InnoDB. Ja esi nolēmis nopietni pie tā piestrādāt, tad nāksies vien ieguldīt darbu izpētē. Metodoloģija, protams, ir ļoti garš un plašs stāsts, savukārt, analīzei un paša servera uzturēšanai ir pieejami diezgan daudz labi rīki.

Manuprāt viens no labākajiem rīkiem ir vienmēr būs laba grāmata. Un MySQL pasaulē labākā grāmata ir High Performance MySQL (patreiz otrais izdevums). Ja Tev līdz šim ir šķitis, ka MySQL ir maza figņa, kura tur kaut kur griežas un nav jāpieskata, tad šī grāmata ikurāt ir domāta tādiem kā Tu. Pašam man tā ir izrotāta ar milzumu grāmatzīmītēm un tiek pāršķirstīta regulāri.

MySQL Enterprise. Ļoti dārgs pakalpojums no MySQL AB, kurš bez maksas tehniskā (un ne tikai) atbalsta sevī ietver arīdzan MySQL Enterprise Monitor, kura izcilās daļas ir MySQL Query Analyzer un MySQL Enterpsise Advisors. Pirmais rīks ir ļoti labs, lai veiktu vispārēju datubāzes noslodzes analīzi, pētot individuālus pieprasījumus vai to grupas. Otrais, savukārt, sniedz padomus par iespējamām nepilnībām MySQL vai paša servera konfigurācijā ar padomiem – kas un kā ir jāmaina, lai viss būtu labi. Tas viss tiek ietverts MySQL Enterprise pakalpojumā, kura cena ir sākot no 2 tūkstošiem dolāru gadā. Tas ir fakts – šis ir viskvalitatīvākais no pieejamajiem rīkiem.

Starp citu, viens no manuprāt būtiskākajiem plusiem ir tas, ka atšķirībā no MySQL Proxy (lai arī risinājums ir faktiski tas pats), šī produkta aģents ir pilnībā caurspīdīgs. T.i. – visas uz IP bāzētās pieejas paliek spēkā un tās nav jāmaina uz @localhost.

Kontrollbase – bezmaksas alternatīva iepriekšminētajam. Projekts ir salīdzinoši zaļš, diezgan bugains, taču ātri gūst popularitāti un arī briedums nāk tam visam līdzi. Biedru ambīcijas ir diezgan nopietnas, jo izskatās, ka viņi vairāk vai mazāk tēmē uz iepriekšējā produkta “fīčām”. Pamēģināju un domāju, ka tuvākā pusgada laikā darīšu to vēlreiz.

Nedrīkst piemirst vēl vienu nopietnu šī tirgus spēlētāju – MONyog. To, tiesa, neesmu mēģinājis, lai arī tas tiek stādīts līdztekus MySQL Enterprsie Monitor.

Savukārt, ja mēs runājam par vienkāršiem rīkiem, kas pamatā dod vienkāršu skaitlisku informāciju, tad to klāsts arī ir neaprobežojas ar vienu vienīgu.

Gana svaigs, bet oriģināls servera skaitliskās informācijas atainošanas rīks ir mycheckpoint. Tas principā ir viens pats nabaga paitona skripts, kurš paver iespēju ģenerēt daudz un dažādas statistikas. Savā ziņā varētu vilkt paralēles ar mazliet modernāku MRTG (neviens, tiesa, neliedz izmantot arī MRTG :P). Izstrāde notiek diezgan aktīvi, kā rezultātā projekts gūst nopietnas aprises un, šķiet, varētu apsavesties arīdzan ar monitorēšanas rīka iespējām.

Ļoti sens, bet aizvien bez maz vai must have rīks ir perlā rakstītais mysqlreport. Tas dara vienkāršu, bet ļoti noderīgu darbu – transformē MySQL statusa vērtības cilvēkam viegli uztveramā formātā.

Tīri no rīku viedokļa ikkatram būtu jāzin maatkit. Tas ir perl skriptu kopums, kuri ir orientēti neba nu uz vienkāršu lietotāju. Ar tiem var paveikt pašu vellu. Par to jaudu var pārliecināties, uzmetot acis vienam pašam rīkam – mk-query-digest, kas ļauj analizēt ne tikai MySQL logus, bet pat tcpdump savāktos datus.

Tas ir tīri par rīkiem, kurus es vairāk vai mazāk ikdienas darbā izmantoju. Kā tos pielietot, kādus secinājumus to darbības rezultātā veikt – tas paliek paša izmantotāja ziņā.

Ja monitoringa vajadzībām tiek izmantots Cacti, noteikti ekipējumā pienākas iegūt MySQL Cacti templates.

MySQL servera dziļākai uzlabošanai pavisam noteikti noderēs Percona Lab izstrādātie patchi (ielāpi), kas, starp citu, vakar tika oficiāli laisti klajā arī MySQL 5.1 sērijai. Nu, un, protams, arī Gūglei ir savi rīki un patchi MySQL serverim (pagaidām tikai 4.x un 5.0.37 versijai).

Visā visumā, pasaule ir pilna ar rīkiem, kas atvieglo vai bagātina ar piedzīvojumiem (atkarībā no roku liekuma rādiusa:) MySQL DBA dzīvi.

Nezinu, kā lai pietiekami uzsveru to, ka, pirms ķerties klāt savam serverim, nepietiek virspusēji iziet cauri tīklos atrodamajai informācijai. Viens konfigurācijas parametrs ietekmē desmit citus – sevišķi tas attiecas uz InnoDB. Lai sekmīgi operētu ar analīzes rezultātiem un ķertos pie uzlabojumiem, ir nepieciešams saprast arīdzan to, kas notiek aiz acīmredzamā. Tā teikt – problēmas cēloni.

Ne vienmēr pietiek iemest serverim ar atmiņu, ātrākiem diskiem un vairāk procesoriem (kas MySQL gadījumā ir atsevišķs stāsts). Piemēram, pie autoritatīviem avotiem ir lasīts par gadījumiem, kad operatīvās atmiņas dubultošana pat ir radījusi pretējo efektu – serveris ir kļuvis lēnāks.

Konkrēti šī neciešamā problēma ir parādījusies dažās Google Chrome pārlūka versijās – tās pa kluso teleportē kazas. Un daudz. Vairāk var palasīties oficiālajā kļūdas #31482 atskaitē.

Ai, aizmirsu iebilst, ka joks pamatā būs saprotams tikai tehniskas dabas cilvēkiem. Un daļai pārējo. Bet nebūt ne visiem.

Papildināts 14. janvārī no rīta. Problēma novērsta.

Tātad, pētot un domājot kļuva skaidrs tas, ka problēma ir ar izejas datiem. Procesa laikā noskaidroju, kas tad galu galā ir shapre faili, un kāda tajos ir informācija. Ātri uzmeklējot devīgajos internetos failus pagasti.shp un novadi.shp, tie nokļuva manā rīcībā. Šajos failos, kā izrādās, ir visa nepieciešamā informācija (poligoni, kuri apraksta pilsētu, pagastu, novadu robežas) UTM koodrināšu sistēmā.

Tālākais jau bija tehnikas jautājums. UTM koordinātas ir iespējams pārkonvertēt uz platuma un garuma grādiem, ja zin to projekciju, kura izrādījās esam WGS84. Izmantojot mazu utilītu ogr2ogr tika iegūts XML fails ar nepieciešamajām koordinātām man vajadzīgajā formātā. Fiksi uzmetot Ipiķus uz Gūgles kartes, viss izskatījās dievīgi (ar daždesmit metru nobīdi dažviet, bet tā nav problēma).

Tālākā iterācija problēmai ir sekojoša. Izmantojam MySQL Spatial paplašinājumus, lai iestumtu datubāzē kā novadu robežas, tā pagastu un pilsētu robežas. Teorijā pēc tam var jebkuram punktam pateikt, kur tas atrodas. Diemžēl praksē MySQL GIS funkcionalitātes iespējas ir gauži ierobežotas un problemātiskas. Piemēram,

laacz@skapis[gis]>  -- Kur ir Ipiķi?
SET @ipiki = GeomFromText('POINT(58.0093006 25.1778021)');
SELECT 
    Within(@point, g) AS `within`, 
    name, 
    type
FROM
    gis 
WHERE 
    Within(@ipiki, g) = 1;
+--------+------------+---------+
| within | name       | type    |
+--------+------------+---------+
|      1 | Ipiķu      | pagasts |
|      1 | Mazsalacas | novads  |
|      1 | Rūjienas   | novads  |
+--------+------------+---------+
3 rows IN SET (0.00 sec)

Lieki piebilst, ka Mazsalacas novads nepārklāj Ipiķu atrašanās vietas punktu nevienā acī, bet MySQL tā nedomā. Tas gan nenozīmē, ka es vaļasbrīžos neturpināšu cīņu :)

Papildināts 21:58. Izrādās, ka MySQL (vēl aizvien arī tekošajā 5.1 GA versijā) operē nevis ar poligoniem, bet gan ar taisnstūriem, kuri šos poligonus pilnībā ietver (bounding rectangles), kā rezultātā neder. PostgreSQL izmantot tikai šiem nolūkiem neredzu jēgu. Tiesa, cilvēki strādā pie tā, lai MySQL ieviestu pilnvērtīgu OpenGIS atbalstu, bet, kā jau MySQL pierasts, tādas lietas nāk ļoti, ļoti lēnām (konkrēti – anonss par testēšanu ir 2 gadus vecs)…

Sveiki, dārgie lasītāji. It sevišķi tie, kuri vēlas paurbt ģeometriju, mazliet paprogrammēt, un pēcāk rezultātus uzdāvināt pasaulei, lai tā kļūtu labāka. Principā, esi sveiks, programmētāj! :)

Uzdevuma nosacījumi ir vienkārši.

Gūgles kartē nepieciešams iezīmēt precīzi jebkura Latvijas pagasta, Republikas nozīmes pilsētas vai novada kontūru. Tas ir izdarāms caur Google Maps API, izmantojot GPolygon klasi.

Lai uzzīmētu kontūru, ir nepieciešami izejas dati. Tos (paldies Mārtiņam) var atrast vikipēdijā (pagasti un novadi, krāsoti novadi). Pirmajā failā (diemžēl, bez komentāriem), ir atrodamas robežas un, kas man ir svarīgi, kārtīgi sagrupēti poligoni visiem Latvijas pagastiem un pilsētām.

Savā piegājienā es paņēmu pirmo – Ipiķu pagastu, kurš tagad ir neatņemama manas dzīves sastāvdaļa, jo ir pirmais pagasts, kurš ienāk prātā, iedomājoties par Latvijas administratīvo dalījumu. Es arīdzan esmu par to informēts vairāk, nekā vajadzētu. Zinu, ka tā platība ir 67 km² un 2000. gadā viņi tur bija 395 (iedzīvotāji). Nu un vēl šo to. Noteikti kādreiz turp aizbraukšu.

Tālākais teorijā ir vienkārši. Mums ir nepieciešams pārrēķināt SVG koordinātas par platuma un garuma koordinātām. Tad, nu, uzinstalēju Inkscape, vāzu vaļā lielo SVG, un provēju izmērīt atrašanās vietu Latvijas galējiem punktiem. Kad tas izdarīts, es uzmeklēju Internetā galējo punktu koordinātas uz Zemes virsmas. Dīvani, bet tajā interneta daļā, kura pasniedz savu informāciju latviešu valodā, šīs koordinātas bija norādītas ar precizitāti līdz minūtei. Attiecīgi, precīzākie dati atradās angļu vikipēdijas Latvijas ģeogrāfijas aprakstā.

Tālāk jau ir diezgan vienkārša aritmētika. Vismaz teorijā tā vajadzēja būt. Izrēķinām to, cik grādus plats mums ir viens horizontālais SVG pikselis, kā arī cik grādus augsts ir vertikālais. Vēl mazas korekcijas, lai iegūtu vienotu bāzi, un aplauziens. Labākais tuvinājums, kuru man izdevās iegūt, ir šāds.

Gala rezultātā (neesmu es nekāds ģeogrāfs vai ģeometrs, ja tādi vispār pastāv) izrādījās, ka koordinātu sistēmas ar vienkāršiem aritmētiskiem līdzekļiem pārrēķināt nevar. Jo. Pastāv zināmas atšķirības starp ģeogrāfisko koordināšu sistēmu un to, kāda tā tiek piemērota “plakanajās” kartēs – viens horizontālais kilometrs klasiskajā kartē būs konkrēts pikseļu, centimetru un collu skaits visās vietās. Kamēr, viens kilometrs uz Zemes virsmas atkarībā no platuma grāda satilpst dažādā garuma grādu, minūšu un sekunžu skaitā. Kas ir vairāk nekā loģiski (vai tā maz var būt? ja var, tad piedāvāju izmatntot terminu paraloģiski).

Aptuveni noskaidrot to, cik kilometrus būs viens garuma grāds interesējošajā platumā, var ar sekojošu formulu:

Kur φ ir platuma grāds, bet a un b ir Zemes ekvatoriālais un polārais rādiuss respektīvi, kuri, kā zināms, atšķiras.

Protams, es kaut kādā brīdī vēl pabakstīšos, bet varbūt kādam ir gana daudz brīva laika un vēlmes, lai isniegtu formulu, ar kuras palīdzību varētu pārrēķināt iepriekšminētās SVG kartes kordinātas uz platuma un garuma grādiem :) Pilnīgi iespējams, ka esmu vēl kaut ko aprēķinos vērā ņemamu palaidis garām.

Realizētājam, pieņemu, mūžīga slava un lauru lapu vainagi garantēti, jo es nebūt neesmu vienīgais, kuru šāda padarīšana interesē. Kā pierādījums faktam kalpos gūgles kartē adekvāti iezīmēts Ipiķu pagasts, kuram būtu jāizskatās apmēram tā, kā to uzzīmē JS iekš balticmaps.eu. Ja vēlamies kontūru, ievadam adreses vai vietas meklēšanas lauciņā Ipiķu pagasts, un uzklikšķinam uz pagasta saites.

P.S. Jā, iespējams, esmu saputrojies ģeogrāfiskā platuma un garuma terminos. Tas lietas būtību diez vai maina. Kā arī, varat iepazīties ar apjomīgu pētījumu par Latvijas centru (centriem, ja būsim precīzi): Kur Latvijai vidus?.

Visiem ir zināms – standarta īsziņa spēj sevī satilpināt 160 zīmes. Ne visiem ir zināms, ka šis nosacījums ir spēkā tikai tad, ja īsziņa satur tikai GSM 03.38 definētos simbolus. Lielākoties tie atbilst ASCII 7 bit simboliem ar dažiem izņēmumiem. Piemēram, visi šie simboli aizņem vienu vietu tais 160 pieļaujamajās zīmēs. Taču. Ir daži simboli, kuri aizņem divas. Piemēram – {, }, €, u.c. Tas nozīmē, ka, ja teksts satur šādas zīmītes, tad pieļaujamais īsziņas teksta garums saīsinās :)

Lai lietas sarežģītu vēl vairāk, pieņemsim, ka tu esi uzrakstījis īsziņu, kura ir garāka par 160 zīmēm. Teiksim – 161. Tādos gadījumos tālruņiem šī viena garā īsziņa ir jāsadala vairākās mazākās. Dalīšanas rezultātā katra īsziņa nedrīkst saturēt vairāk par 153 teksta simboliem (GSM gadījumā – septetiem), jo klāt nāk dienesta informācija, kura ļauj saņēmējam tās atkal apvienot pareizā secībā. Tātad, 161 zīmes gadījumā nosūtīsies divas īsziņas, kuras saturēs 153 un 8 teksta septetus. Tehniski tie būs septeti, bet nu…

Tagad, teiksim, tu sagribēji nosūtīt īsziņu, kurā ir kaut viens vienīgs “ā”. Tādos gadījumos īsziņas kodējums no iepriekšminētā GSM alfabeta tiek mainīts uz UCS2 (konkrēti – UTF-16 big endian), kā rezultātā katrs īsziņas simbols, neskatoties uz to – sevišķais vai parastais, aizņem jau divus baitus. Aritmētiski tas saīsina vienuīsziņu līdz 70 zīmēm. Ja tās garums pārsniedz 70 zīmes, tad katra daļa nesaturēs vairāk par 64 zīmēm.

Teorijā šādu daļu skaits var būt 255. Praksē parasti to skaits nepārsniedz 7. Pie kam, operators tarificē katru no šīm daļām kā vienu īsziņu.

Kopsavelkot – bez speciālajiem simboliem viena īsziņa var saturēt līdz 160 simboliem, bet pēc tam notiek īsziņu dalīšana, no kurām katra var saturēt līdz 153 simboliem. Ar speciālajiem simboliem vienas īsziņas garums ir 70 simboli, bet, ja tas ir garāks, katra daļa saturēs 64 simbolus.

Kaut kā tā. Iespējams, ka esmu mazliet saputrojies skaitļos vai definīcijās, bet virspusēji tas viss izskatās ikurāt šādi. Vēl var parunāt par SMPP, un to, ka tur viss notiek ar baitiem, nevis septetiem, kas rezultējas ļoti daudz dažādās viltībās iekš tā – kā īsziņas saturs GSM alfabeta gadījumā tiek vai netiek transformēts pie operatora, pirms nonākt līdz lietotājam. Un arī otrādāk :)

Jautājums: Kas ir rekursija?

Atbilde: Skat. jautājumu.

Vai arī pavaicā visuvarenajai un visuzinošajai gūglei.

Krutākais nav saistīts ar pašu Apple. Vismaz tieši. Pateicoties licences līguma nosacījumu maiņai, beidzot uz šī aparāta būs arī TomTom. Interesants šķiet arī statīvs, kurš nodrošina ne tikai aparāta turēšanu, bet uzlabo tā GPS uztveršanas spējas, un kalpo kā bezroku sistēma. Starp citu, pats Apple šāda tipa aksesuāru (mašīnas montāžas kitu) nepiedāvā. Vai vismaz nepiedāvāja, kad interesējos.

Sāksim ar to, ka vakar vakarā tika anonsēts jaunā iPhone versija – iPhone 3G S, kuras nosaukumā S nozīmē speed. Kardinālu novitāšu nav. Ātrāks esot. Kamera tagad ir trīs megapikseļi ar autofokusu un video filmēšanas opciju. Man tas gluži nepieciešams nav. Ir kompass (ļauj kartei pašai pagriezties virzienā, kurā skatās telefons). Atbalsta 7.5 megabitu HSDPA datu pārraidi. Principā tas arī viss no dzelžu viedokļa.

Apple vēsta, ka jaunais modelis Latvijā būs pieejams sākot ar 7. jūliju. Protams, ka neviens neko nezin par cenām. AT&T 8GB 3G maksāšot 99 dolārus, bet 3GS – 199 un 399 par 16 un 32GB versijām respektīvi. Papildus tam, mūsu valstī nav ierasta lieta, kas citviet ir tikai normāli – piedāvāt esošajiem klientiem tādu kā apgreida iespēju uz jaunāku tālruņa modeli. Tas nozīmē, ka, visticamākais, tālrunis būs jāpērk par jaunu, lai arī subsidēts un līdz ar to arī lētāks, nekā citur.

Līdz ar jauno iPhone ir atjaunināta arī tā programmatūra, kura būs pieejama arīdzan iepriekšējiem modeļiem. Plaša patēriņa segmentā tā tiks laista klajā 19. jūnijā.

Beidzot ir ieviesta copy and paste iespēja. Tiesa, tā darbojas arī uz tekstiem un bildēm no weblapām, ko var attiecīgi, piemēram, iepeistot e-pastā. Vajadzēja jau viņiem kaut vienu ieganstu, kāpēc tas nebija līdz šim. MMS – niecīgu popularitāti guvušais pakalpojums Latvijā. Bet, nu, labi. Ir. Beidzot ir realizēta iespēja klaviatūru lietot horizontāli pamataplikācijās, kurās šīs iespējas nav bijis līdz šim. Kalendāra aplikācija ir piedzīvojusi izmaiņas, kuras bez interfeisa ietver sevī arī CalDAV atbalstu (hooray!). Labāks pārlūks, kā jau tas ierasts ar šiem apdeitiem. Stereo Bluetooth atbalsts. Rakstīts, ka atbalsta piezīmju sinhronizāciju. Ja tas darbosies arī caur ActiveSync, būšu priiecīgs.

Viena no visgaidītākajām iespējām ir iPhone izmantošana kā modemam – lai tam varētu pieslēgt datoru un internetot uz nebēdu. Nav teikts, ka tas darbosies pie mums, jo ne visi operatori tam ir piekrituši dēļ sevis piedāvātajiem datu pārraides tarifu plāniem.

Vairākas jaunas iespējas ir radušās tiem, kas izmanto MobileMe – var atrast savu zudušo tālruni, izdzēst tā saturu, atskaņot kādu signālu vai arī parādīt uz ekrāna paziņojumu.

Visas detaļas un manis neuzskaitītos jaunumus var izlasīt internetos. Par to – vai es iegādāšos jauno modeli, – vēl nezinu. Viss ir atkarīgs no kopējās cenas cenas, potenciālajām līguma izmaiņām, savas tā brīža rocības un citu atsauksmēm.

Starp citu, kādu brīdu tagad esmu pastaigājis ar Samsung Omnia HD. Nekad nebūtu ticējis, ka šī kompānija var izveidot tādu telefonu (man pietika ar C100:), kurš pat man patīk. Sasodīti biju pārsteigts. Protams, nav tam arī tikai plusi, bet par to citreiz.

Aiz kam ne?

Esmu ieviesis savā blogā viltīgu pretspama filtru. Tas darbojas tā, ka visiem komentāru formas laukiem tiek priekšā pievienota ņekaja vērtība, kura ir pirmie desmit simboli no md5 heša no tekošā datuma. Šī vērtība tiek aprēķināta divreiz – pirmo reizi komentāru lapā, kad to iekešo lietotāja proksis (rezultātā – padodamā vērtība var būt novecojusi). Otro reizi komentāru pievienošanas brīdī, kad tas aprēķina (meklējamā vertība ir tekošā). Rezultātā – padotā vērtība nesakrīt ar gaidāmo un wordpress uzskata, ka nav aizpildīti nepieciešamie lauki.

Eksistē maģiska funkcija, kā unpack(). Konkrētajā gadījumā man no četriem secīgiem baitiem nepieciešams “izpakot” 32 bitu naturālu skaitli big endian baitu secībā. Nekādu problēmu. Neskatoties ne uz ko, tas vienmēr ir izdevies bez problēmām. Šodien, uz kādas 64 bitu sistēmas radās nepieciešamība palaist attiecīgo skriptu nevis zem PHP4, kā līdz šim, bet nu jau zem PHP5 (uz 32bit PHP5 problēmu nav). Un tad nu sākās.

list(,$command_id) =  unpack('N', \
    chr(0x80) . chr(0x00) . chr(0x00) . chr(0x09)); 
# Iegūstam -2147483639 

Tas nekas, ka reāli tas ir negatīvs skaitlis, neskatoties uz unpack norādīto informāciju. Sekojošais kods visu noliek savās vietās un iegūstam pozitīvu skaitli:

$command_id = hexdec(dechex($command_id)); 
# Iegūstam 2147483657 

Taču, uz 64bit PHP5 man šāda operācija pēkšņi sāka izsniegt skaitli 1.8446744071562E+19. Neiedziļinoties detaļās – kāpēc tā, sapratu, ka esmu nepareizi darījis. Tā vietā, lai atrisinātu problēmu ar pirmo atrasto metodi, man vajadzēja to saprast līdz saknei un risināt ar pirmo pareizo. Un tā būtu:

$command_id &= 0xffffffff;

Šis atrisina problēmu uz 64bit sistēmām, un neko nesalauž uz 32bit. Kā jau minēju, uz tās pašas kastes PHP4 uzvedās korekti.

Microsoft Dynamics AX datubāzē datums tiek rakstīts kā normāls DATETIME lauks. Bet, kā izrādās (ja ticēt integratoriem), laiks, savukārt, ir jāraksta atsevišķā kolonnā. Nebūtu jau nekas tāds nenormāli baiss, ja Axapta nepieprasītu laiku rakstīt kā parastu skaitli, kurš norāda sekundes kopš pusnakts (!).

Tālāk jau sekoja ātrs uzrakstījums (jo optimālāku metodi nemeklēju).

zakainop.transactiontime = \
    notification.ts.strftime('%H') * 60 * 60 + \
    notification.ts.strftime('%M')) * 60 + \
    notification.ts.strftime('%S')

Vai jums šķiet, ka es panācu vēlamo rezultātu? Jo rezultātā ieguvu teksta virkni, kurā stundas atkārtojās 3600 reizes, minūtes – 60 reizes un sekundes bija vienu reizi galā. Ibo, visiem (arī man bija) zināms sekojošais.

'kaka' * 2 # Būs 'kakakaka' 

Lieki piebilst, ka es par to biju piemirsis un neiedomājos, ka overflow iestājas ikurāt šā iemesla dēļ. Vēlējos tikai pazīmēties, cik dažreiz esmu dumjš.

Programmētājs darba intervijā.

- Kāds bija iemesls aiziešanai no iepriekšējās darbavietas?

- Intraneta izstrāde un testēšana.

- Slikti izstrādājāt?

- Nē, atlūguma iesniegšanas forma darbojas izcili.

Bet galvenais jautājiens – kuru CMSu cilvēki varētu ieteikt mazam intranetiņam? Drupālu, vai? Gribētos, lai autentifikāciju varētu nomainīt no iebūvētās uz LDAP, un citas korporatīvas figņas fiņiņas.

Tad nu, tālu vairs nav tā diena, kad vārda kārns vietā ierakstot dokumentā vārdu krāns, dators ne tikai to palabos, bet arī ar nīgri (koeficients 0.6) pasmīkņās.

No otras puses, var jau arī ikdienas pielietojumu atrast pat šitik jocīgai specifikācijai. Piemēram, automatizētās sejas/personu atpazīšanas sistēmās. Vai arī sociālajos tīklos paplašināt un standartizēt cilvēka emocionālo stāvokli (poke:). Var arīdzan aprakstīt emocionālo komponenti kādam dialogam, piemēram.

Uzskatāmībai strīdīgi jautrs paraugs.

<emotion>
    <appraisals set="Scherer_appraisals_checks">
        <novelty value="0.8"/>
        <intrinsic-pleasantness value="-0.5"/>
    </appraisals>
</emotion>