Vai Mac ir arī programmētāju labākais draugs?

Līdz šim es biju diezgan vienaldzīgs pret Mac fanātiķiem, kas jūsmoja par to, kā viss uz Mac ir labāks. Man likās, ka visbiežāk šie Mac entuziasti bija no grafikas / video / audio dizaineru un mākslinieku loka un es pieņemu, ka viņiem tiešām Mac varētu būt piemērotāks.

Bet pēdējā laikā manu uzmanību ir piesaistījis tas, ka daudzi “top programmētāji” arī ir pārslēgušies uz Mac. Daži no piemēriem:

• Ruby on Rails core team ar David Heinemeier Hansson priekšgalā visi lieto Mac. Viņu labākais draugs uz Mac ir TextMate, kurš tiešām izskatās viens no labākajiem teksta redaktoriem programmētāju vajadzībām. TextMate radītāji arī ir tik fanātiski “makisti”, ka atsakās portēt šo teksta redaktoru uz Windows vai Linux (patlaban izmēģinu tā atdarīnājumu uz Windows – e teksta redatoru – un jāsaka, ka pat atdarinājums ir tīri labs).
• Droši vien ka Ruby kopienas iespaidā arī pragmatiskais programmētājs un daudzu labu grāmatu autors Dave Thomas pirms kāda laika ir pāslēdzies no Linux uz Mac.
• Smalltalk programmētājs un Seaside web applications framework radītājs Avi Bryant lieto Mac.
• Lisp programmētājs un pirmā application service provider radītājs Paul Graham raksta, ka aizvien vairāk viņam zināmie hakeri pārslēdzas uz Mac.
• Atlassian programmētāji arī lieto Mac. Viņi ir radījuši populārās Java bāzētās JIRA issue tracking un Confluence wiki sistēmās.
• Līderu izvēle ietekmē arī sekotājus – skats no RailsConf 2006 🙂 Saka, ka arī Java konferencēs parādās arvien vairāk MacBooki.

Kādi varētu būt galvenie iemesli Mac popularitātes pieaugumam “top” programmētāju vidū?

• Pragmatiskais apsvērums ir tāds, ka ne-Microsoftiskie programmētāji visticamāk savas aplikācijas produkcijā darbinās uz Unix/Linux veidīgajiem serveriem, un tādā gadījumā OS X vai Linux uz savas darbstacijas ir daudz noderīgāks, lai topošo sistēmu izstrādes laikā izmēģinātu uz sava datora. Un lai arī cik labi būs wizardi programmēšanas IDE rīkos, vislielāko produktivitāti varēs sasniegt programmētājs, kas pārzinās Unixa komandrindas spēcīgās iespējas.
• Savukārt izvēli par labu OS X nevis Linux var raksturot ar Dave Thomas citātu – “I switched to Macs a couple of years ago after being a Linux person for more than 10 years. The tools are not necessarily better, but they don’t have to be sharpened or maintained as often, which lets be concentrate on just using them.”
• Un papildus, kas man likās būtiski, ir tas, ka izvēli par labu Mac izdara tie programmētāji, kas par būtiskām programmatūras īpašībām uzskata lietojamību un estētisku vienkāršību – iespējams, ka tas, ja programmētājs lieto estētisku un vienkārši lietojamu Macu stimulē viņu radīt arī estētisku un ērti lietojamu programmatūru.

Šo novērojumu rezultātā es vairs neesmu tik skeptisks pret Mac un OS X entuziastiem 🙂

EDOC faila formāts

Pagājušā gada beigās beidzot saņēmu savu īsto e-me e-paraksta karti un tagad varu turpināt izpēti e-paraksta pielietojuma jomās.

Viena no pielietojuma jomām ir e-me izstrādātā aplikācija e-Parakstītājs, kas nodrošina failu un atbilstošo e-parakstu glabāšanu e-me izstrādātajā EDOC formātā, kas ir balstīts uz XAdES standartiem.

Izmēģināju parakstīt ar e-Parakstītāju vienu failu test.txt un rezultātā ieguvu failu test.edoc, kas ir šajā EDOC formātā. Paskatoties test.edoc “vēderā” redzams, ka tas ir ZIP fails, ar sekojošu direktoriju un failu struktūru:

_rels
=== .rels
docProps
=== Core.xml
EDoc
=== _rels
====== manifest.xml.rels
=== docProps
====== Base.xml
====== Papildus _pa__bas.xml
=== Documents
====== test.txt
=== Signature
====== _rels
====== origin.sgns
====== signature1.xml
[Content_Types.xml]

No šīs visas failu struktūras saturīgā informācija pamatā atrodas tikai test.txt (parakstāmais fails) un signature1.xml (paraksts šim failam). Vai rezultātā EDOC formāts nav uztaisīts kā lielgabals šaušanai pa zvirbuļiem? Pirmais piemērs šai pārāk lielajai EDOC formāta sarežģītībai jau ir, ka e-me.lv pieejamās EDOC apstrādes Java bibliotēkas nav savietojamas ar e-Parakstītāja radītajiem EDOC formāta failiem. No readme.txt:

Currently signature objects are not compatible with signature objects created by MS “EDOC Authoring” tool and vice versa, due to potential inconsitencies in EDOC specification.
We are working to resolve that limitation.

Kāda būs visbiežākā vajadzība lietot e-parakstu? Visbiežāk, manuprāt, tā būs tikai viena faila parakstīšana – 1) vai nu tiek parakstīts kāds iesniegums valsts vai pašvaldību institūcijai, un attiecīgi arī atbilde no šīs institūcijas, 2) tiek parakstīts kāds viens līgums starp divām pusēm, 3) tiek parakstīta kāda biznesa transakcija (piemēram, maksājums). Visos šajos gadījumos daudz ērtāks, manuprāt, būtu vienkāršāks XML formāts (kas arī varētu būt bāzēts uz XAdES), kurā varētu vienā failā iekļaut gan parakstāmo dokumentu, gan vienu vai vairākus parakstus.

Bet gan jau prakse parādīs, vai un kā šis EDOC formāts tiks lietots. To varētu ietekmēt arī tas, vai MK noteikumos tiks precizēts, kādi faila formāti jāizmanto elektroniskā paraksta glabāšanai. Dotajā brīdī MK noteikumos ir rakstīts

10. Elektroniskajam dokumentam izmanto šādus datņu formātus:
10.1. nenoformētam tekstam – TXT;
10.2. noformētam tekstam – RTF, SGML (XML);
10.3. grafiskai informācijai – JPEG, TIFF vai PNG;
10.4. vektoru grafikai – CGM.

Tā ka tur nekas nav rakstīts par EDOC formātu (kas pat nav XML formāts), tad dotajā brīdī jebkura valsts vai pašvaldību institūcija var mest atpakaļ saņemots EDOC failus, paskaidrojot, ka nespēj apstrādāt neko citu kā TXT, RTF un XML 🙂