A mai informatika egy teljesen vak fejlesztő szemével III.

Vakok irodai munkájáról szóló cikksorozatom utolsó darabja Dr. Papp Lászlótól, aki mint szoftverfejlesztő a fejlesztés vakokat segítő specifikumairól is komoly ismeretekkel rendelkezik. Remélem, a szakmabelieknek hasznos információkk

Fejlesztésspecifikus részletek hardcore informatikusoknak

Vakok irodai munkájáról szóló cikksorozatom utolsó darabja Dr. Papp Lászlótól (előző részek itt és itt) , aki mint szoftverfejlesztő a fejlesztés vakokat segítő specifikumairól is komoly ismeretekkel rendelkezik. Remélem, a szakmaibelieknek hasznos információkkal szolgál, és esetleg a jövőbeli fejlesztések ezáltal is jobban használhatók lesznek a vakok számára is. Az alábbiakból többnyire a kötőszavakat és mellékneveket értem csak :) így ha esetleg kérdésetek van, szívesen továbbítom azokat Lászlónak, aki érdemben tud válaszolni.

- Mivel a mainstream fejlesztőeszközök nem tartoznak a szinte mindenki által használt appok közé, a képernyőolvasók fejlesztői nem írnak külön beállításokat és scripteket ezekhez (vagy ha igen, akkor nagyon alapszintűt, pl. Visual Studio), ezért az IDE-k és egyéb vizuális eszközök használata sok csapdát rejt, ami nagyban nehezítheti a munkát. Ezért jelenleg is minimalista fejlesztőkörnyezetekkel dolgozom, általában egyszerűbb programozáscentrikus szövegszerkesztőkkel (pl. Notepad 2, Notepad ++) és parancssori toolchain-ekkel (leginkább GNU eszközökkel) és scriptekkel (pl. batch fájlokkal, vagy shell scriptekkel).

Az IDE-k világában üdítő Kivétel a Purebasic nyelv IDE-je, ami 100 %-ban, erőlködés nélkül, kényelmesen használható, ami igen ritka. De már pl. az elterjedt és nagytudású Code::Blocks IDE érdemben használhatatlan, pedig azt nagyon szívesen használnám. A form designerek nem tudják betölteni rendeltetésüket képernyőolvasókkal használva, mivel a point-and-click munkamenet nem igazán lehetséges a szem helyett kizárólag képernyőolvasóra támaszkodva. Ha user interfészt kell programoznom, akkor ezek helyett én erős vizuális képzelőerőmet használom (valaha láttam) és fejben kimatekozom, mi hová kerüljön. Határozottan működik, de hogy igazán hatékony lenne, azt azért nem állítanám.

- A vizuális jellegű guideline-k betartása (pl. megkövetelt indentáció) nagy extra figyelmet követel, lassítja a munkát, és növeli a tartalmi hibák esélyét. Így van ez annak ellenére is, hogy a képernyőolvasók adnak bizonyos segítséget az indentáció változásának érzékeléséhez. Forráskódoknál ezen a nehézségen pretty printer appokkal lehet segíteni, amik megoldják az indentációt helyettem „okosban”. Indentációra épülő blokkstruktúrája miatt a nagyon elterjedt Python programozási nyelv nem a szívem csücske, ha lehet, én ezt a jóval kevésbé elterjedt, de igen magas szintű Icon/Unicon nyelvcsaláddal váltom ki, amiből egyébként a Python sokat merített.

- Az ingyenes képernyőolvasók nem alkalmasak olyan remote desktop típusú megoldások lekezelésére, ahol a szerver pusztán az ernyőképet küldi át a kliensnek. Windows-on bizonyos ilyen architektúrákra (pl. Citrix) van megoldás, ennek ára legálisan azonban igen borsos (közzé sem teszik a honlapjukon, csak telefonon lehet érdeklődni a pontos árakról), és ezt csak a remote desktop infrastruktúrát működtető cég rendelheti meg. Ilyenkor a megvett terméket (Jaws for Windows Pro with remote access option) mind a szerveren, mind a kliensen futtatni kell, és megfelelő kommunikációjukat konfigurálással kell biztosítani.