DSL
Jelen esetben nem volt alternatíva a klikkelgetéssel konfigurálható felület, mivel jogszabályokban szövegesen megfogalmazott szabályokat kellett tudni leírni, mint kalkulációs szabályt. És a egyrészt annak a szabad szövegnek szabadságfokát lehetetlen lefedni előre gyártott form funkcionalítással, másrészt a jogalkotót (parlament) elég nehéz lett volna rávenni, hogy a mi megoldásunk korlátaiban gondolkodjon csak. És ráadásul ez évről-évre változik és a rendszer szabály igazítását nem szerette volna beszállító cégfüggővé tenni.
Egy kereskedelmi példa mire lehet még jó:
Értékesítési rendszerben valamilyen árkedvezmény konstrukciók kialakíthatósága a követelmény. Formos megoldásban mondjuk klikkelhető, hogy rendelés összege alapján hány százalék a kedvezmény.
A DSL annyival több(jobb), hogy teszem az jön egy olyan későbbi igény: a Budapesti telephelyű szálítók akik az elmúlt évben 10milliónál nagyobb összegben rendeltek, vagy 5 éve folyamatosan évi 5millió felett rendelésük az kap kedvezményt. Ehhez nem kell semmilyen formmódosítás, fejlesztés, hanem rögtön írható be a szabály felhasználó által.
Nem értek azzal egyet azzal a feltételezéssel, hogy jellemzően kell szakértői segítség. Ha elegendő mintapélda áll rendelkezésre a felhasználónak, akkor copy-paste és kisebb módosításokra degradálódik a leprogramozása egy új szabálynak. Ehhez minden cégben található megfelelő képességű ember.
Fegyvertársam mondá vala: A nyelvet szabd a problémára, ne fordítva. Ez a DSL. Olyan szókincset adni a felhasználónak, amit ért és tud benne "programozni".
Skálázhatóság
Lényeg a terhelés szétoszthatósága, és az erőforrások rugalmas bővíthetősége.
Egyik része
Elején nem tudtuk megbecsülni sem, mekkora terhelést jelent ha 4000 user egyszerre nyomogatja a rendszert. Potenciálisan ennyi lehetett volna. Az a problémakör sajátosságából fakad, hogy előállhat olyan csúcsterhelés, amikor mindenki dolgozna, ráadásul kéne mennie a nagy ROLLUP-oknak is.
Skálázhatóság ez esetben: hogyha kell, akkor be tudunk állítani 1 nap alatt mégegyszer ekkora szerverparkot. (Zárójelben az egész alkalmazás környezet leáll és újraindul 1 percen belül - disktől függően.)
Másik része
Feladatok párhuzamosíthatósága.
Pl.:
valahol van x, y, z deklaráció
(progn (pararell (set x (+ 1 1)) (set y (+ 2 2)))
(setf z (+ x y))
Azaz két szálon, akár külön gépen kiértékelt az x, és y, majd ismét valahol a z. Ehhez ennyit kelljen írni és ne többet. Oké, nem mindenhol van rá szükség de ha x és y kalkulációja önmagában 1 óra, akkor már érdekes hogyan terheled az erőforrásokat.
Hatékonyság
Gyorsan végeztünk, mert produktív a technológia. Sajnos meg kell élni, tudom nehéz elhinni bemondásra.
Modellezés, GUI, kimutatás fejlesztés mind-mind nagyságrendekkel gyorsabb. Kisméretű a kód és nagyon jól olvasható (a végére az ügyfél is tudta már olvasni), a debugolás és úgy általában egy fejlesztési/javítási ciklus töredék a többi technológiához képest.
Nincs átírom, fordítom (néha az egész világot újra), felpatchelem a szervert, esetleg újra belépek, újra elgyaloglok a hibához és megnézem most mi van. Egyszerűen futás közben befordíthatsz akár pár soros módosításokat, refresh és ott a változtatás. Ez nem a mi érdemünk, hanem a LISP-nek és az SBCL-nek köszönhető.
De látni, méginkább kiprobálni kell