Man tā vajadzība pēc GPS radās mazliet citā sakarā – diezgan daudz pārvietojos ar velo, gan ar konkrētu mērķi, gan arī kaut kur klīstot. Rezultātā vajadzība ne tik daudz zināt, kur atrodos konkrētā brīdī, cik vēlme ierakstīt maršrutus un vēlāk jau skatīt to visu uz kartes un ģenerēt jaunus maršrutus. Tādām iekārtām ir arī nosaukums – GPS tracker un tos mēdz lietot arī biezās auto signalizācijās, tikai tur vēl papildus GPS čipam nāk arī GSM modulis, kas iegūtos datus ļauj pārsūtīt uz serveri. Man neko nekur sūtīt nevajag, tapēc skatos, kas ta veikalos ir dabūjams. 
Telefona variants jau izmēģināts gadus 5 atpakaļ, īpaši neapmierina tīri dēļ maksimālā laika bez uzlādes – dažas stundas mani galīgi neapmierina. Par iPhone vispār nerunājot – tas ar ieslēgtu ekrānu labi ja 2h nodzīvo. Protams arī ekstremāliem apstākļiem (lietus, dubļi, triecieni) šādi verķi īpaši nav piemēroti.
Tātad paliek specāli šādiem mērķiem taisītas lietas – Garmin,  Magellan. Paskatos ciparus – nu nē… Mani apmierinoši modeļi maksā latus 200 un uz augšu. 
Tad kaut kādā brīdī acīs iekrīt Holux GPSport 245, kuram gan tūlīt būs piejama arī svaigāka un advancētāka versija – Holux GPSort 260, bet tā kā tā vēl nav pieejama pārdošanā, iepērku veco. Aktuālās cenas šeit, mans pirkts par 45Ls.
Principā tas ir tas pats GPS Tracker, taču ar būtisku bonusu – ekrānu, kurā var redzēt visu aktuālo informāciju. Tā nav navigācija, lai arī viens navigācijas elements ir funkcionalitātē iekļauts, bet par to vēlāk.

Tātad, iesākumam sausi tehniskie dati:

Tālāk, komplektācija:

• Diezgan necilā kartona kastītē mājo pats Holux GPSport 245.
• Vēl necilāka instrukcija uz vienas lapas, uz kuras vēl pietam ir satilpinātas vairākas valodas.
• Daži savilcēji, kaut kāds gumijas gabaliņš un velo stūres stiprinājums.
• Pievienojama cilpa, kas ļauj iekārt mūsu iekārtu rokā, kokā, stabā, stabā…
• Lādētājs 220V ar miniUSB otrā galā.
• Vads datoram – USB <-> miniUSB.
• Draiveru, programmatūras disks priekš PC (ar serial number uz vāciņa).

Te uzreiz varētu būt viena atkāpe – iekļautā programmatūra, draiveri ir tikai priekš windows. BET, es jau iepriekš biju izzinājis, ka arī mac un, protams, arī linux viss notiek. Macos varu ieteikt myTracks – patiešām lieliska programmatūra ar virkni integrāciju gan macosx iekšpusē (iPhoto, Aperture), gan arī uz ārpusi – iespēju publicēt maršrutus webā, iegūt, saglabāt informāciju par geocaching, exportēt un skatīties maršrutu google earth un daudz, daudz ko citu (ko pievienotā programmatūra nepiedāvā). Uz iPhoto un Aperture, protams attiecas geo koordināšu pievienošana bildēm. Katrā ziņā tas notiek tik vienkārši, ka nav pat īpašas jēgas stāstīt:) Ideja tāda, ka fotokamera pie katras bildes saglabā tās uzņemšanas laiku (te gan vajadzētu atcerēties uzlikt kamerai pareizu laiku), GPS tracker, savukārt zin, kur tieši tajā laikā mēs atradāmies. Tālāk jau, kā saka, “ģelo tehņiki”..

Lietošana
Lietošana sākas ar uzstādīšanu uz velo. Līdzi nāk parastie savilcēji, tos tad arī pielietojam. Ar turētāja uzstādīšanu problēmas nerodas, taču mazliet esmu vīlies, ieliekot pašu iekārtu turētājā. Nepavisam neizskatās stabili – tracker tik ļoti izbīdās uz priekšu, ka viens neveikli paņemts zars var rezultēties ilgos pasētās iekārtas meklējumos. Te nu talkā nāk cilpa (skatīt bildēs), kas sākotnēji likās absolūti nevajadzīgs aksesuārs – cilpu apmetu ap stūres iznesumu, pašu iekārtu turētājā un nu jau izskatās ok. Ja arī kaut kas notiks – iekārta paliks karājoties.

Īpašas problēmas nerodas arī konfigurējot – viss ir pietiekami saprotami un atrodami. Kādu brīdi gan ir pauze, kad mēģinu saprast, kurā vietā uzstāda laiku. Tā kā tādas vietas nav un laiks ir līdz riebumam precīzs, nolemju, ka arī tā ir info, kas nāk no satelītiem. Vispār jāatzīst, ka konfigurēšanas iespējas ir patiesi plašas. Gan attiecībā uz pašiem logošanas uzstādījumiem, gan arī uz attēlojamo informāciju. Vārdu sakot – šeit esmu pilnībā apmierināts, uzstādu logošanas laiku 1sec vai 10m un dodos ceļā. 
Ceļā viss notiek – sasodīti ātri sakonektējas ar satelītiem un sāk rādīt visādas jaukas lietas. Ekrāns pārredzams, glīti rāda pārvietošanās ātrumu un vēl šādu tādu pietiekami noderīgu info. Dažu parametru patiesumu gan varētu apšaubīt – piemēram patērētās kalorijas. Arī mans pulsometrs rēķina kalorijas, taču pie nosacījuma, ka es tiešām to pulsu mēru. Tātad ir vismaz kaut kāds paramers, kuru varētu uzskatīt par izejas punktu. Smieklīgs liekas ekrāns, kurš uzrāda ietaupītā CO2 līmeni un pat izglābto koku daudzumu:) 
Tas tā kā viss jauki, bet mani interesē, ko tad sanāca ierakstīt. Tas tad arī ir pirmais darbiņš atgriežoties mājās – pieslēdzam pie datora, izeksportējam datus, skatamies. Skaisti. Maršruts ir, ātrumi ir, augstums virs jūras līmeņa ir, visas lietas. Koordināšu precizitāte arī šķiet visai solīda. Te gan būtu jāpiezīmē, ka dažas dienas vēlāk braucot caur Vecrīgu gan sazīmējas visādi brīnumi – droši vien no māju sienām atstarotie signāli. Bet tas viss sīkums – iegūtais rezultāts mani pilnībā apmierina.

Gandrīz piemirsu – par navigācijas iespējām. Iekārtai var ievadīt 5 punktus (gps koordinātas), kurus vēlāk var izvēlēties šīs vietas atrašanai. Punktus, protams var uzsetot arī gaitā – aizbraucot uz kādu vietu to vienkārši pieglabāt un vēlāk izmantot atpakaļceļa atrašanai. Nekāda dižā navigācija no tā nesanāk, taču vismaz rāda virzienu un attālumu līdz izvēlētajam mērķim. Patiesībā pat šodien noderēja – kūlos cauri mežam un galīgi apjuku gaidītā dzelzceļa vietā ieraugot parastu asfaltētu ceļu.. Paskatījos kurā virzienā ir mājas un tapa skaidrs, ka caur mežu esmu izbraucis nevis taisnā līnijā, bet cilpu un esmu atgriezies uz tā paša ceļa, no kura sāku:)
Vai šis var aizvietot velodatoru? Nevar. Velodators rāda aktuālo ātrumu, GPS tomēr ir kaut kāda laika intervāla vidējais. Ja aktuālā ātruma zināšanai nav tik ļoti izškirošas nozīmes, tad laikam jau var arī iztikt ar vienu šādu verķi uz stūres.

Rezultāts
Varētu jautāt, kas tad bija tas, ko es vēlējos panākt? Šis ir tas rezultāts (ja rāda jūdzes, uzbraucot uz kartes labā apaksējā stūrī ir settings ikona, kur visu var saregulēt) - šajā gadījumā web publicēts šodienas maršruts, bet tik pat labi tas varētu būt arī parats gpx failiņš vai jebkāds cits formāts vai veids kā paskatīties pašam sadarīto, kā arī parādīt citiem. Šajā brīdī varētu pareklamēt arī vienu LV lapu – http://veloride.lv/ , kur arī ir iespēja importēt gpx maršrutus, ievērtējiet:)

Plusi, mīnusi
Tagad jau tā grūti kaut ko formulēt, jo es jau pirms tam biju izpētījis iespējas un apzinājos ko tā iekārta var un ko nevar. 
+ plašas konfigurēšanas iespējas
+ akumulatora darbības laiks
+ ātrs satelītu atrašanas laiks (patiešām, tik ātru vēl nekad nebiju redzējis) un “ķer” pat telpās
– stūres stiprinājuma “šaubīgais” izpildījums
– iebūvēts, nemaināms akumulators (var jau būt, ka tā ir labāk korpusa hermētiskuma nodrošināšanai) 
– saglabājamo punktu varētu būt vairāk par 5 (tad varētu izmantot kaut vai geocaching)

- atmiņas apjoms varētu būt lielāks vai papildināms ar atmiņas karšu palīdzību (bet tas tāds aiz matiem pievilkts mīnuss – ar 200 000 punktiem logošanai vajadzētu pietikt)

Un nobeigumā Bildes (var skatīties arī tur, ja tā ērtāk)

Agriežoties pie web izstrādes – kas mums tagad notiek serveru pusē? Nāk jauni webserveri ar jaunām iespējām un, protams, ātrāki vai kā citādāk labāki par iepriekšējiem – Nginx, Lighttpd, kuri liek pabīdīties Apache, IIS. Nāk jauni datu kešošanas mehānismi – memcache, lai arī nu jau gandrīz vecs, taču jau tiek pielietots un iedzīvināts arvien vairāk citās, kuras izmantojam web projekta darbināšanā. Ja kādam ar memcache key-value mehānismu ir par maz, talkā nāk Redis, Tokyo Cabinet.
Nevar nepieminēt arī vēl vienu lietu – saucamo noSQL risinājumu parādīšanos. Kaut kādā mērā tā tendence ir iepriekš minēto vajadzību segšanai, bet var jau būt ka arī šādam piegājienam ir arī nākotne. Pagaidām grūti spriest par ieguvumiem vai trūkumiem. Par piemēru paņemot kaut vai MongoDB – kaut kas pa vidu starp memcache un klasisku RDBMS. No vienas puses nav vairs primitīvs memcache, no otras, lai arī nevaram pielietot klasisku SQL sintaksi, datus tomēr var paprasīt pēc kaut kādiem parametriem šajā gadījumā izmantojot JSON. Jebkurā gadījumā šādu pazīstamu paņēmienu izmantošana varētu arī palīdzēt MongoDB attīstīties.

Kaut kur visa šī datu apstrādes mehānismu starpā gribētu atrast arī nišu datu indeksētājiem – Sphinx, Lucene/Solr. Ļoti ērts veids panākt performances pieaugumu esošos projektos (kaut gan var izmantot arī topošos, ja ir zināms, ka plika DB nepavilks), īpaši vietās, kur līdz tam izmantotas sarežģītas datu atlases. Pie kam izmantojami ne tikai kā fulltext meklētāji, bet arī kategorizētiem datiem. Es savulaik Sphinx izmantoju dēļ lieliskās iespējas meklēt arī objektus pēc to ģeogrāfiskā attāluma, bet darbu gaitā sphinx tika pielietots daudz plašāk.

Tiesa gan par to visu liela daļa izstrādātāju var tikai pasapņot, jo hostingi defaultā mums nepiedāvās ne mongo, ne sphinx. Labākā gadījumā tur būs memcache atbalsts. Protams visu var sarunāt un vēl viena klienta iegūšanai visticamāk šis hostinga kantoris arī būs gatavs uzlikt nepieciešamo, bet individuāla pieeja arī individuāli maksā. Tā ka šajā sakarā vēl viena tendence, kas iegūst lielāku popularītāti – VPS jeb virtual server hostings. Nav mums gluži izdalīts dzelzis, taču visu instalēt un darīties varam kā uz īsta.

Skatoties tālāk – kas jauns pašā programmēšanas frontē? Šķiet, ka te gan nekas būtisks nemainās pagaidām. Esošās valodas attīstās, bet no jauna nekas baigo popularitātes vilni nav piedzīvojis. Vienu lietu gan gribas pieminēt – flash. Ir zināms par kariem starp Apple un Adobe par flash neesamību iPhone, Ipod Touch, iPad un šī cīņa jau ir apnikusi:) Un te nu seko manuprāt viens no ģeniālākājiem Adobe soļiem – native iPhone aplikācijas flashā. Te viens video par tēmu. Labi, priekš iPhone varbūt arī nedaudz novēloti, taču priekš iPad pašā laikā. Tirgus plašs, iespējas attīstībai vēl jo lielākas nekā iPhone, jo nav visādu tur operatoru ierobežojumu un cenas/kvalitātes/iespēju attiecība pietiekami sakarīga. Flash izstrādātāju arī vairāk, nekā ojective-c. Personīgi es šo iPad attīstību gan saredzu ne tik daudz spēlītēs vai aplikācijās, bet tekstuālā satura – avīžu, žurnālu, grāmatu izplatībai šādā e-saturā.

Un nobeigumā:) Nobeigumā es gribētu pieminēt vārdu “ideja”, jo tas ir tas ar ko viss sākas. Ideja ir visas attīstības pamatā – ir ideja, ir tās materializācija, ir lietas, kuras mēs ikdienā lietojam vai lietosim nākotnē tieši pateicoties kādai senai vai ne tik senai idejai. Un es varu tikai novēlēt tev un arī sev – lai mums ir šī ideja un iespējas to realizēt:)

Labi, pietiek muldēt, jāķeras pie lietas:)
Bet lieta sekojoša – kādu brīdi atpakaļ gribējās pamēģināt tādu lietu, kā Amazon s3, jeb statisku failu hostēšanu kaut kur citur, nav pat obligāti šis s3, tā vietā varētu būt jebkas cits. Pamatojums? Trafiks. Tieši uz šiem statiskajiem failiem (img, css, js) tas saskrien visvairāk. Amazon tādā ziņā ir labs, ka mani faili tiek izmētāti pa visu pasauli uz n-tajiem serveriem un klients to dabū no sev tuvākā, ātrākā. Mīnuss – tas tomēr ir maksas pasākums. Lai arī ļoti minimālas maksas, taču maksas.
Domāts, darīts – piereģistrējos s3, sakopēju savus failus, salieku webā src=amazon, bet kaut kā nav īsti smuki – visādi sveši url figurē, plus tas viss salīdzinoši notiek diezgan lēni.

Un šajā brīdī atcerējos par nginx un tā iespējām:

location /s3redirect {
   rewrite ^/(s3redirect)/(.*)$ /s3/$2 break;
   proxy_pass http://alxf1lv.s3.amazonaws.com;
   proxy_redirect off;
   proxy_set_header Host alxf1lv.s3.amazonaws.com;
   proxy_set_header X-Real-IP $remote_addr;
   proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 }
 

Un vualā – lapā varu atbrīvoties no amazon linkiem, tā vietā lietojot it kā lokālu folderi /s3redirect. Rewrite paredzēts tam, lai pārrakstītu s3redirect par s3, jo tieši tādā folderī mani dati stāv uz amazon servera. Bet otra problēma saglabājas – lēnums. Jo katrs pieprasījums vienalga brien uz amazon. Galarezultātā pat sanāk lēnāk, nekā pa tiešo, jo pieprasījums vēl iziet lokālo stadiju:) Nu ko, turpinam rakt un pieslēdzam cache:

location /s3proxy {
   rewrite ^/(s3proxy)/(.*)$ /s3/$2 break;
   proxy_pass http://alxf1lv.s3.amazonaws.com;
   proxy_redirect off;
   proxy_set_header Host alxf1lv.s3.amazonaws.com;
   proxy_set_header X-Real-IP $remote_addr;
   proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

   proxy_cache_key         backend$request_uri;
   proxy_cache_valid       200  1h;
   proxy_cache_use_stale   error timeout invalid_header;
 }
 

+

html {
   ..........
   proxy_temp_path /usr/local/nginx/proxy_temp;
   proxy_cache_path  /usr/local/nginx/cache  levels=1:2   keys_zone=one:180m  max_size=500m;
}

Vēlamais efekts panākts – faili stāv uz amazon, taču servējas jau no lokālā dzelža, kas gan, protams, izklausās stulbi, jo faili jau sākotnēji var stāvēt lokāli, taču domājot plašāk, paveras pietiekami plašas scalability iespējas.

Jāteic gan, ka es neapstājos pie sasniegtā:)  Ideja “a kā būtu servēt no atmiņas” realizējās šādā nginx konfigurācijā:

location /s3 { 
    set $memcached_key $uri;                  
    memcached_pass     127.0.0.1:11211;    
    error_page 404 = @fetch;
}
location @fetch {    
    proxy_pass http://alxf1lv.s3.amazonaws.com;  
    proxy_redirect off;  
    proxy_set_header Host alxf1lv.s3.amazonaws.com;
    proxy_set_header X-Real-IP $remote_addr;  
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;   

   proxy_cache             one;  
   proxy_cache_key         backend$request_uri;
   proxy_cache_valid       200  1h;  
   proxy_cache_use_stale   error timeout invalid_header; 
}

+

html{
   .................
   proxy_temp_path /usr/local/nginx/proxy_temp;
   proxy_cache_path  /usr/local/nginx/cache  levels=1:2    keys_zone=one:180m  max_size=500m;
}

Jeb cilvēciskākā valodā – fails tiek servēts no memcache, ja tur nav – no proxy un ja nav arī tur – no amazon:) Jā, sviestaini, un jā, diez vai es to reāli izmantošu, bet kā neliels ieskats nginx iespējās, domāju, diezgan ok:)

Testi (100 secīgi pieprasījumi 73Kb lielam failam):

Pa tiešo no amazon s3          62.5762 sec
Redirect                       63.1520 sec
Redirect + proxy               1.071 sec
Redirect+ proxy + memcache     0.1760 sec

secinājumus varat izdarīt paši:)

Jāpiebilst gan, ka šādā konfigurācijā memcache māk tikai lasīt – dati pirms tam kaut kādā veidā tur ir jādabū iekšā. PHP piemērs par šo tēmu – kaut vai šeit beigās. Bet, jebkurā gadījumā, tas ir pietiekami būtisks mīnuss.

Bet varētu šo problēmu atrisināt arī savādāk – ar viena cita nginx moduļa palīdzību – NginxHttpMemcModule, kurš memcache māk arī rakstīt.

iPad. Ir jau daudz visa kā slikta sarakstīts par šo produktu – protams trūkumiem – gan dzelziskiem, gan softiskiem. Atkārtoties nav vēlmes. Bet ziniet, kādus gadus atpakaļ jau sēžot dīvānā bija vīzijas par šāda tipa iekārtu, kuru varētu izmantot kā papildinājumu lielajam kompim – respektīvi – ekrāns man klēpī, bet procesi tiek stumdīti lielajā kompī. Un man šķiet, ka šīs vīzijas varētu arī piepildīties – paņemam kādu no remote display softiem AppStorē (piemēram šo) un darbinam visu ko ienāk prātā. Uzreiz momentā atkrīt nepilnvērtīgā OS mīnusi, tāpat arī multitasking lietas utt. Papildus tam varam arī neslēgties pie lielā kompja un izmantot iPad visos tajos veidos, par ko stāstīja Džobss.
Lūk jums reāls iPad pielietojuma pluss. Ja remote display softs ir gana labi uztaisīts, tad ar darbošanās ērtumu problēmām nevajadzētu rasties.

Visādi citādi, ja man jautātu vai iPad ir revolucionārs produkts? Nē:) Nu vismaz ne tik revolucionārs, kā savulaik bija iPhone.
Vai tas ir tāds, kād gaidīju? Nu, taisnību sakot, man bija vienalga kāds viņš būs. Jāteic, ka visvairāk biju vīlies par OS, lai gan bija jau gaidāms, ka gaidāmo iekārtu darbinās iPhone OS. Pie tehniska rakstura nepilnībām iPhone jau ir pieradinājis un ar iPad nav vairs tas sāpes asums:)
Vai es pirktu? Kamēr nebiju līdz tām remote lietām aizdomājies, likās pilnīgi useless produkts. Tagad tāds 50/50.
Te gan vairāk piestāvētu jautājums – vai man vajag? Pilnīgi un noteikti ne:) 
Un ar šo arī varētu beigt, turpinājums komentāros:)

Dzelzis – iepriekšējās paaudzes iMac (Early 2008) 24″, 3.06 GHz, 500Gb HDD, 4Gb RAM, NVIDIA GeForce 8800 GS 512Mb

Atskaites punkts – vēl uz 10.5.6 versijas laisti Geekbench testi – 4124 punkti.

Tagad ar 10.6 :
32bitu režīmā (OS palaista uz 64bit) – 4312 punkti.
64bitu režīmā – 4748 (!!!) punkti.

Tātad pieaugums patiešām  ievērojams un kas dīvaini – pat sajūtams:)
Pagaidām ar to arī beigšu, jāskatās tālāk:)

Kāpēc es gribu 29er  – nu izlekt vajag, protams:) Bet ja nopietni – gribas pamēģināt ko jaunu un man kaut kā šķiet, ka šis varētu būt tas, ko vēlos. Bet es neesmu mēģinājis kā tas ir un komentāros vēl varat mēģināt mani atrunāt no šī soļa. Patiesībā droši vien būtu labi dzirdēt kādu reāla lietotāja atsauksmi, ja vien tādi vispār ir.
Protams, es apzinos niecīgo riepu, dakšu izvēli un droši vien vēl kaut ko, bet tas pagaidām liekas otršķirīgi.

Turpinājumā dažas bildes ieskatam (aci cenas pēc esmu uzmetis uz 1. eksemplāru – superior 829, pārējie bik tā kā par sālītu):

1superior09_829v

◄ Back

Next ►

Picture 1 of 5

P.S.
Par gadījumu ar nosperšanu – atstāju gaišā dienas laikā, pietiekami civilizētā apkārtnē ričuku uz auto jumta saslēgtu ar veloturētāju (MontBlanc Discovery). Pats jau vien vainīgs, protams, pat nepadomāju, ka tas varētu būt risky.. Domas par velo upgrade gan bija jau gadus 2-3, bet žēl vienalga.

Diezgan bieži mēdzu izmantot arī video uzņemšanu (Cycorder), paretam arī SwirlyMMS. Ne tas būtiskākais moments, taču man patīk arī, ka varu pamainīt vizuālo paskatu – skinus (Winterboard) komplektā ar LiveClock un LiveWeather, kas uzreiz uz attiecīgajām ikonām parāda aktuālo laiku un temperatūru. Bez tam vecais 2G ir nācis no USA un ar LMT nedraudzējas:) Tātad iemeslu jailbreikam joprojām ir vairāk nekā pietiekami:)

Par 3.0. It kā jau viss visādos i-net resursos ir pateikts – visādas papildus iespējas, bet ņemot vērā dīvainos softiskos ierobežojumus 2G versijai, pārāk lielā sajūsmā neesmu:) Uzrāvos arī uz pārspīlēto stabilitātes optimismu, jeb novākto iespēju apturēt uzkārušos aplikāciju paturot 6sec home pogu. OK, tas bija kaut kāds softs ne no AppleStore, bet Cydia, bet nu uzkārās. Home pogas turēšana vairs nepalīdz. Labi, ka es zināju jauno kombināciju softu apturēšanai (iziešana uz poweroff dialogu un pēc tam 6sec home), bet nu neērti.
Patiesībā jau arī upgreids negāja baigi spoži. Nē, uzlikās viss čotka, norestrējās dati un viss srādāja smuki. Nākamais etaps bija atjaunojot Cydia softus ar APTBackup palīdzību – arī viss it kā smuki atjaunojās, bet viss šis sports beidzās ar mūžīgo restartu:) Tad kad kādas 3x pēc kārtas no šī burvīgā “brick” stāvokļa neizdevās ielīst DFU režīmā, likās jau, ka nu jau cauri ir, bet kaut kā beigās tomēr sanāca un viss čiki – tiku pie restore iespējas.

Kas attiecas uz 3G S, tad nenoliedzami tas ir no “gribu” sērijas:) Vairāk gan 3MPix kameras, video, kompasa dēļ, nevis tās spēļu platformas pēc.
Atgriežoties pie tulkošanas – priecē, ka šoreiz nav tādas strukturālas izmaiņas failu sistēmā, kādas tās bija pie pārejas uz 2.x versiju. Tātad teorētiski šoreiz vajadzētu būt mazliet vieglāk un mazāk arī visādu softu savietojamības problēmām.

OS. Linux. Nav nozīmes kāds distributīvs, pa lielam visi viņi savu funkciju pilda. Šobrīd, izstrādes vidē, darbojas CentOS, bet tas ir tikai tāpēc, ka viņš tur jau bija:) Ar visu savu saimniecību, kas man absolūti nav vajadzīga. Tāpēc man patīk BSD sistēmas, kurām sākotnēji nav nekā vispār un var salikt tikai to, kas tiešām nepieciešams.

Webserveris. Lighttpd. Nekādu problēmu. PHP FastCGI modē un visas lietas. Patiesībā viena lieta mani mazliet pārsteidz saistībā ar manis izmantojamo gettext. Protams ir izstrādāts normāls web interfeiss tulkošanas lietām, sajūgts arī ar mysql, bet ne par to stāsts. Stāsts par to, ka biju lasījis, ka pēc jebkurām gettext izmaiņām jārestartē webserveris lai izmaiņas stātos spēkā. Manā gadījumā ir tā, ka tas notiek pats no sevis. Patiesībā ar kļūdu – pirmais php requests pēc gettext update beidzas ar 500. kļūdu, bet pēc tam viss notiek it kā nekas nebūtu bijis un arī izmainītie, jaunie teksti strādā.
Turpinot par PHP – CodeIgniter framework kā MVC “groži” tika atstāts. Tiesa gan reāli sākot darbināt diezgan drīz uzradās lietas, ko gribējās savādāk, kā arī situācijas, kad bija vajadzība mazliet izkāpt no CI uzliktajiem rāmjiem. Pirmais, kas cieta, bija sesiju apstrādes library. Oriģinālais tika nonests, vietā uzlikts “native session“, papildināts ar memcache. Iemesls diezgan triviāls – šis CI oriģinālais sesiju handleris arī datus storēja pa savam, bet es orientējos uz izstrādi, kur paredzēta vieta serveriem, uz kuriem nu nekādi nav vēlmes stutēt augšā CI. Piemēram bilžu/failu upload. Tā kā man nebija cilvēcīgas iespējas no šiem serveriem tikt klāt pie sesijas datiem, tad vieglākais ceļš bija nonest šo neparocīgo risinājumu:)
Vēl CI tika papildināts ar pāris pašrakstītiem libraries memcache un gettext supportam. Mamcache gadījumā jauns CI library, kā arī papildnāts sesiju library. Gettext gadījumā updeitots language library.
CI uzliktie izstrādes rāmji (MVC), gan dažreiz mazliet samazina izstrādes ātrumu, taču vairumā gadījumu tomēr palīdz noturēt kodu saprotamu un viegli updeitojamu. Nestandarta situācjās, kad ir vēlme izdarīt to, ko it kā neparedz CI, tas ir elementāri izdarāms griežoties pie CI instances pa tiešo ($CI = & get_instance();) un kā tika novērots, tad šis paņēmiens arī nerada kādas vērā ņemamas problēmas noslodzes vai ātrdarbības ziņā.

Dati. Trijotne – mysql, memcache, sphinx. Ar memcache viss bija skaidrs, tiesa gan pie nepietiekoša atmiņas daudzuma sāka rasties ievērojama CPU noslodze, bet tas vairāk bija dēļ tā, ka uz 1GB RAM tika mēģināts palaist visu, visu – webserveri, mysql, sphinx, memcache utt. Protams, ka tas dzelzis nīka ārā, jo 2Gb bija swapā:)
Ar mysql pagaidām cīnos, jo performance salīdzinājumā ar pārējiem datu handleriem ir nožēlojama un man pagaidām nekādi neizdodas to panākt ciešamu. Taisnības labad gan jāsaka, ka neesmu vēl īpaši mēģinājis tur kaut ko optimizēt. Īpaši vērā ņemams lēnums ir attiecībā uz kombināciju “insert on duplicate key update ”.  Atsevišķās vietās nācās arī nomainīt insertus ar “delayed insert” un sekojošu innodb -> myisam pāreju attiecgajām tabulām. Frontend galā tīru select uz mysql gandrīz nav nemaz – tiešajiem datu selektiem starpā memcache, datu atlasēm – sphinx.
Attiecībā uz mysql, nākamais pētāmo lietu sarakstā ir Falcon storage engine, bet par to man pagaidām komentāru nav.
Ar sphinx bija dažas nianses attiecībā uz datu indeksēšanu un patiesībā vairāk uztveramas kā sphinx bugs, bet par to tagad sīkākos iztirzājumos neizplūdīšu. Galarezultātā un arī pateicoties mysql lēnumam, sphinx tiek izmantots krietni plašāk, nekā biju plānojis sākumā. Plānots bija tikai geo lietām, bet tagad tas darbina arī visādas datu relāciju lietas, kā arī indeksētus filtrus, keywordus, fulltext search utt. Vienīgā problēma ir neliela datu izmaiņu aizture, bet ar dažādiem paņēmieniem to ir izdevies samazināt līdz minimumam (1-2sec). Patiesībā ir doma kaut kad tās sphinx lietas tīri no praktiskā viedokļa iztirzāt atsevišķā bloga ierakstā.

Client side , UI risinājumi. Ļoti daudzveidīgi. It kā vairums gatavu risinājumu – jqueryUI, ajax forms, jcrop, swfupload,  utt, bet lielu daļu nākas stipri pielāgot gan vizuāli, gan funkcionāli. Atsevišķs stāsts varētu būt par Google Maps API, priekš kā pat sākotnēji tika uztaisīta tāda lieta kā marķeru nepārklāšanās princips – čekojot marķeru atrašanās rādiusus, jeb poligonus. Diemžēl pagaidām šo principu esmu atslēdzis, jo Internet Explorer javascript renderēšanas ātrums ir vismaz 10x mazāks, nekā jebkuram citam browserim un nekas nav mainījies arī IE8. Iespējams, ka nāksies atteikties arī no ajax json datu saņemšanas principa – arī šī paša iemesla pēc. Par IE runājot – arī IE6 vizuālā renderēšanas īpatnības hvz cik papildus izstrādes laika prasošas un droši vien ir saprotama problēma jebkuram web izstrādātājam:)

Nobeigumā, jeb secinājums. Ir sajūta, ka aptuveni mēnesis pirmsizstrādes izpētes un plānošanas laika ir bijis gana noderīgs, jo ir izdevies izvairīties no nopietnām problēmām pašos izstrādes principos un lietojamajos rīkos. Lielākā problēma patiesībā bija koncepcijas iztrūkums pašam projektam – tikai tādas vīzijas skiču un mutiskā veidā. Attiecīgi neiespējami kaut ko pietiekami precīzi izplānot laiku un resursu ziņā. Tas, protams, aiz sevis pavelk arī tādas lietas kā prasību maiņas, redizainu utt. It kā jau visu paši arī daram – paši domājam kā labāk, paši pēc tam pārtaisam, bet manuprāt ir ļoti lietderīgi vienreiz pasēdēt un patiešām padomāt, nevis ķert karstu un sākt taisīt pat īsti neapjaušot ko:) Tas tā – it kā mācība priekšdienām, kura tomēr vienmēr atkārtojas no jauna:)

Paīss gan tas izbrauciens šoreiz sanāca – 3.5 dienas, jo pirmkārt – Venēcija tomēr ir padārga vieta, otrkārt – nebija diezko pārliecības, ka spēsim tos mazos ilgāk “paciest” un viņi mūs un treškārt – kaut kad jau jāstrādā arī ir:)

Bija labi un laiciņš arī lutināja ar ~30C laikā, kad te bija uz pusi mazāk.

Emocionālā daļa tika aprakstīta draugos, te lai paliek tehniskā puse:) Tad nu tā – Venēcijā noderēja gan navigācija, gan mac netbook. Vairāk gan otrais, jo pretēji hoteļa aprakstiem, wi-fi internets tur tomēr bija pieejams un bez papildus samaksas.

Labi, ko tur daudz stāstīt – ja kas būs jautājams, pajautāsiet. Tālāk lai runā ceļojumu otrā krāsainākā daļa – bildes:) (Pirmā vietā tomēr iespaidi un atmiņas)
Ja nu nepatīk šāds apskates veids, tad var skatīt arī tur, labākā kvalitātē.
[[Show as slideshow]]

Mana atbilde uz šo jautājumu – Dell Mini 9. Perfekta, 100% dzelžu saderība ar Apple Mac OSX.

Protams, rūdītiem macistiem būs saprotami iebildumi – hackintosh ir zaimošana, dažreiz pat principa lieta. Tāpat arī pieņēmumi, ka ar hackintosh viennozīmīgi gaidāma kāda dzelžu nesaderība, līdz ar to problēmas, līdz ar to – nepareizs priekšstats par Mac OSX. Bet kā pārliecinājos uz savas ādas – viss strādā un nekādu problēmu, kas būtu saistītas ar dzelžu nesaderību, nenovēroju. Gluži otrādi – uz macos dažas iespējas pat ir vairāk, nekā uz windows vai linux, bet par to vēlāk.

Manā rīcībā esošā Dell Mini 9 specifikācija (es gan uzreiz brīdinu, ka tā ir max iespējamā šim modelim):

Intel ® Atom™ Processor N270 (1.60GHz, 533MHz, 512K cache)
Integrated 1.3MP Camera
LCD 8.9″ WSVGA (WLED) Truelife Display
2048MB 533MHz Dual Channel DDR2 SDRAM
64GB Solid State Hard Drive (Mini PCIe PCI-e)
Integrated Intel® Graphic Media Accelerator 950
Dell 802.11b/g Wireless LAN Mini-Card
Bluetooth® Internal (2.0) Mini-Card
4-cell Lithium-Ion Battery (32 WHr)

tātad samērā tipiska komplektācija priekš netbook, ja neskaita 2Gb RAM un 64Gb SSD, kas skaitās daudz. Protams, varētu vēlēties lielāku ekrānu, vai vismaz lielāku rezolūciju, bet pie tā diezgan ātri pierod. Pat pēc 24″ mac:)
Cena, par kādu tika iepirkts šāds zvēriņš – 280Ls. Un ar LV 3 gadu garantiju (es gan nezinu kapēc 3, jo parasti ir 1 gads). Cena droši vien būtu zemāka, ja būtu hdd, nevis ssd, bet priekš šādas komplektācijas cena manuprāt ir ļoti ok.

Vizuāli ļoti pievilcīgs. Viegls (1Kg), mazs (ērti iebāžams palielākā kabatā). Man gan bija kaut kādi aizspriedumi pret netbookiem un ar bažām skatījos uz izmantoto materiālu un salikšanas kvalitāti, bet te nav kur piesieties. Starp citu, vieglāks un mazāks arī par MacBook Air, ja nu vienīgi biezāks un švakāks pēc statusa:)

Ekrāns mazs (1024 x 600px), bet visnotaļ lietojams. Pie kam vajadzības gadījumā var pieslēgt arī pie normāla izmēra monitora caur visparastāko VGA izeju. Nebūs, kā mac dzelžu gadījumā, jāmeklē kārtējā video pāreja. Bet ekrāns patiesi kvalitatīvs. Protams led backlight, glancēta virsma, normāli apskates lenķi dara savu, bet varu apgalvot, ka patiešām patīkami lietot.

I/O – 3USB (2 kreisā, 1 labā pusē), karšu lasītājs (SD/SDHC, Memory Stick). Uz macos tikai nestrādā MMC, bet tas jau arī diezgan novecojis formāts. Vēl jau pieminētā VGA izeja un audio i/o austņām, mikrafonam. Un vēl RJ45 10/100 LAN caurums tīkla kabeļa piespraušanai.

No integrētajām lietām – WiFi 802.11g, Bluetooth 2.0, 1.3MPix webcam. Un viss, viss pilnvērtīgi strādā arī uz macos. Starp citu arī integrēti skaļrunīši neatsit gluži lētus pīkstuļus – skan ļoti ok.

Klaviatūra, touchpad. Nevajadzētu sagaidīt brīnumus – aparāts ir izmēros mazs, līdz ar to arī klaviatūras taustiņi mazi un sablīvēti. Esmu gan pasūtījis Dell updeitotu klaviatūru, kur tas izkārtojums ir mazliet sakarīgāks. Par touchpad ir atsevišķs stāsts. Censoņi ir uztaisījuši uzlabotus draiverus (skat. bildēs) šai mazajai ierīcei un līdz ar to uzlikšanu strādā arī visādas iespējas, kas standartā tur nav pieejamas – 2 pirkstu scroll, kā normāliem maciem. Var izvēlēties arī “karstās” malas un skrollēt pa touchpad malām, kā tas ir ierasts windows laptopos. Un tādas lietas kā click vai drag, par ko standarta draiveros varētu tikai pasapņot.

Un kas vēl – pilnīgi un abslūti kluss. Es neesmu dzirdējis no šī datoriņa nevienu mehānisku skaņu un patiesībā pat nezinu, vai viņam vispār ir kāds ventilators iekšā. Iekārtas, kas vismaz kaut cik varētu liecināt par kādu aktivitāti – hdd, arī nav. Teorētiski vajadzētu būt lielākai noturībai pret nejaušiem triecieniem, bet to man kaut kā negribas testēt:)

Ak jā, gandrīz piemirsu – viens no svarīgākajiem laptopu parametriem – darbības laiks no baterijas. Teikšu kā ir – pie nepārtrauktas darbošanās, mocīšanas, testu laišanas izvelk gandrīz 4 stundas. Varētu būt vairāk, bet ir labi arī tā.

Papildus informācija:
Komūna par dell mini 9 dzelžu, softa upgreidiem -
http://mydellmini.com/

Par macosx instalēšanu uz mini -
http://mydellmini.com/forum/faqs-and…A%B9s-f55.html

Bildes, apraksts -
http://i.gizmodo.com/5156903/how-to-…e-os-x-netbook

Modificētie touchpad draveri –

http://mydellmini.com/forum/touchpad-drivers-t5577.html

Performances testi:
Patiesībā, štrunts par testiem – šis kompītis neatstāj lēnuma iespaidu nevienā acī. Protams, full HD filmas nepavilks, taču ar visu pārējo ikdienā lietojamo softu problēmām nevajadzētu rasties. Bet nu labi, lai būtu testi un salīdzinājums ar citiem manā rīcībā esošajiem dzelžiem:
2005. gada iBook G4 -
http://browse.geekbench.ca/geekbench2/view/119682 – score 515 (PowerPC G4 1.33 GHz)
Dell mini 9 -
http://browse.geekbench.ca/geekbench2/view/130618 – score 931 (Intel Atom N270 1.60 GHz)
vecs mājas pc -
http://browse.geekbench.ca/geekbench2/view/71381 – score 1370 (Intel Pentium 4 3.00GHz)
un mājās darbināmais 3GHz iMac -
http://browse.geekbench.ca/geekbench2/view/119663 – score 4124 (Intel Core2 Duo E8435 3.06 GHz)

un ja vēl ņemam vērā to, ka šajos testos netiek ņemts vērā hdd ātrums, tad ātruma testos nesalīdzināmais ssd dod vēl savas priekšrocības.
Tā ka manuprāt visnotaļ pieņemama performance priekš tāda maza cinīša:)

Negatīvie aspekti:
Lai nebūtu tā, ka tikai medus vien, vajag arī kādu darvas pili:) Bet patiesībā arī tās piles tādas mazas jo mazas. Ir pāris lietas, kuras manī izraisīja nelielu vilšanos -
1) Parallels desktop atteicās instalēties, jo redz neesot savietojami dzelži. Līdz ar to manas retās vajadzības pēc windows, jeb virtuālajām mašīnām būs jāapmierina citur.
Papildināts: problēma atrisināta uzliekot Sun VirtualBox un uz tā jau win xp.
2) Sleep mode. Viss strādā- aiztaisam vāku – aizmieg, attaisam – normāli pamostas, lai gan dažas sekundes jāuzgada, kamēr wifi pamostas, bet tik tālu viss normāli. Es tikai vēlētos, lai sleep mode mazāk ēd bateriju, savādāk pa nakti savi 10-15% tiek nograuzti. Bet ņemot vērā, ka OS pilnas ielādes ilgums ir tikai 30-35sec, sleep varētu arī neuzskatīt par problēmu.

Bildes: