LAACZ.LV

Jebkuram izstrādātājam ir skaidrs, ka versiju kontroles sistēma ir jālieto. Gan tad, kad strādā viens, gan tad, kad strādā mazā kolektīviņā, gan tad, kad strādā pie maziem projektiņiem. Ja Tev tā nešķiet, tālāk vari nelasīt un komentāru formu vari lieki nesmērēt. Arī to, ka klasiskās VCS (SVN, CVS [rly?]) ir gana jaukas, lūdzu, neminam, jo visiem skaidri zināms, ka patiesība ir DVCS pusē.

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.

Kamēr Tavs mazais blodziņš vai e-veikaliņš lēnām vago interenta āres ar saviem tris simtiem apmeklētāju dienā, nav par ko uztraukties. Bet, ja Tavam MySQL serverim ir savi daži simti pieprasījumi sekundē, no kuriem daudzi nav optimizēti dažādu apstākļu sakritības rezultātā, ir vērts sākt domāt. Provēt izrakt visu dažādas kvalifikācijas un dažādu cilvēku desmit gadus rakstīto kodu? Vai varbūt tomēr pieķerties lietai no otra gala?

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.

Es, kā saka, paliku bez desām. Visām. Kā pakritu, nekontrolēti rēkdams un asaras liedams, zem galda, tā tur arī paliku [pārspīlējums]. Šķiet, ka nav daudz bug reports klases joku, par kuriem es būtu šitik nenormāli smējies. Pameklēt var iekš mūžam izcilā StackOverflow.

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.

Vakardienas izpēte un jūsu komentāri rezultējās ar nežēlīgiem panākumiem.

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)…

Papildināts 11. novembra 0:15. Pavei tik – Ipiķi Gūgles kārtē kā dzīvi, sasodīts! Sīkāk par to vsu kādu citu dienu. :)

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.

Šodien tviterī ieradās jautājums par to – cik īsziņas gala rezultātā tiek nosūtītas, rakstot tās garākas par 160 zīmēm. Tad, nu, tā kā tviterī būt izsmeļošam ir pagrūti, tad paprovēšu atbildēt šeit.

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 :)

Šodienas dedzinošākais ieraksts (technisks, protams) ir par to, kā ar ne gluži vienkāršu SQL vaicājumu (vienu) var uzzīmēt ASCII grafiku. Tur pat nav ko piebilst.

Par programmēšanu.

Jautājums: Kas ir rekursija?

Atbilde: Skat. jautājumu.

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

Man kā esošam iPhone lietotājam teju vai ir pienākums uzrakstīt kaut ko par jaunumiem šai sakarā.

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.

Starp citu, vai neviens nav iedomājies, ka daļu aprēķinu varētu nodot lapu apmeklētāju datoriem ar visvienkāršāko metodi? Kaut vai, izmantojot to pašu Gūgles ieviesto map-reduce principu. Serveris katram apmeklētājam iedala mazu uzdevumiņu pie, kuru tas, kad izrēķina, atdod atpakaļ serverim. It sevišķi, pie mūsdienu pārlūku cīņas par JS ātrdarbību tas varētu būt diezgan labs veids, kā, piemēram, iekš milzīgas apmeklētības lapām ielikt SETI@home vai Folding palīgskriptiņu – Gūgle, Digg, u.c.

Aiz kam ne?

Atvainojiet tie, kas nespēj šad un tad iekomentēt. Problēma, pateicoties Krotow, ir lokalizēta un nākamnedēļ, kad atgriezīšos no slēpošanas brauciena, to plānoju salabot. Ja nu interesē, kas par lietu, varu paskaidrot.

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.

Es, šķiet, pirmo reizi mūžā šodien saskāros ar problēmu, kuras sakne ir tanī, ka 32bit sistēmas un 64bit sistēmas ir ne pārāk viegli savietojamas.

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.

Vakar pavadīju aptuveni trīsdesmit minūtes, lai atrisinātu neskaidru problēmu. Īsumā – SQL serveris pie UPDATE vaicājuma paziņoja, ka kaut kāda vērtība ir ārpus pieļaujamajām robežām.

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.

Spicausis ieskaiperēja ar saiti uz dokumentu, par kura nepieciešamību var aizdomāties tikai specifiskas vielas lietojot. Veco 1.0 internetu laikos mēs, lai elektronizētu smaidu, rakstījām “:)”. 1.5 internetu laikos tas viss masveidā tika aizvietots ar emotikoniem – smaidīgiem apaļiem bumbuļiem bildīšu paskatā. Tagad, kad sakarā ar 2.0 viss ir izdarīts, bet 3.0 ir versija tam, kas nekad nebūs, W3C inkubatora pārstāvji ir ķērušies pie emocijām, radot EmotionML 1.0.

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>