Adam Nemeth’s Blog

Kértétek, itt van. Alapvetően itt a modultervezésről lesz szó, a komplett rendszerek tervezése egyrészről picit más tészta, másrészt ebből a szempontból meglepően sokszor van megkötve a kezünk. Érdemes elolvasni a cikket is, de a kapcsolódó két esettanulmány a legértékesebb talán.

Ha a specifikáció megvan, hányszor adjuk oda tetszőleges, az implementációs környezetet valamelyest ismerő kollegának azt, már implementált (és titokban: tesztelt) terméket várva vissza cserébe? Mi sem természetesebb ennél, nem igaz? Az alkotói szabadság, a modulok amúgyis függetlenek, a srác amúgyis megbántódna, ha beleszólnának a dolgába… ugye?

Hát egy lúf.szt.

Alapvetően a kód azon részei, amit senki nem menedzsel (nem látja senki a készítőjén kívül), fekete dobozok. A fekete doboz pedig nem elhanyagolható valószinűséggel lehet rossz, hibás. Azt, hogy megvalósítja-e egyáltalán a specifkációt, csak akkor tudjuk, ha ténylegesen leteszteltük (amit általában szintén a programozóra bízunk..). A specifikáció gyakorlatilag mindig interfészspecifikáció: azt mondja meg, adott interfésze(ke)n keresztül milyennek tűnjön a program. Lehet ez UI, lehet ez adatbázis, de lehet épp másik programrész.

A tervezés elsődleges feladata, hogy részekre válassza a megoldandó feladatot, a részek közti összefüggéseket (interfészeket) pedig rögzítse. Tehát eme fázis nem más, mint részekre bontás, és részspecifikálás.

(more…)

Ez már majdnem kód… bocsi, kitaláltam valamit, kell a gondolatmenet felépítéséhez ennek az ismerete… Meg aztán remélem, haszonnal forgatjátok, megismerkedtek egy olyan eszközzel, amiről eddig sokszor csak előítéleteket hallottatok…

A modellek sokszor folyamatokat írnak le, nem struktúrákat (Beiratkozás az egyetemen, forrás: Agilemodeling.com)

Az előző postban elejtettem, hogy “a diagramjaim rendszerint rövidtávra készülnek”. Ez egy nagyon fontos mondat, szeretnék rajt elidőzni.

A modellezésről a legtöbb embernek a Model-Driven Development jut eszébe, ami egy szép elméleti elképzelés, a gyakorlatban viszont nehéz kivitelezni, bár vannak működő rendszerek, főleg bankoknál.

Pedig a modellezés fontos része a programozásnak, enélkül nem lehet átlátni a szoftvereket, nemhogy minőségi programot írni.

(more…)

Az informatikának az elmélete és gyakorlata néha élesen kettéválik egymástól. Két tábor van: az egyik tábor - ők vannak kevesebben - megpróbál az elméleti principiumok mentén létrehozni egy akadémiai alapokra épülő szakmát, ahol a dolgok folyamata valamiféle profi rend szerint történik.

A másik tábor - ők vannak többen - az egyetemi tudás jó részét hasztalannak tartja, a saját életére nem érzi alkalmasnak.

Az Architect dolgok nem titkolt célja, hogy bemutassa az utóbbi tábor tagjainak, hogy igenis, érvényesek az ő életükre is ezek a szabályok. Az pedig, hogy nem így csinálják, hiányosság, ad absurdum legtöbbször hiba.

Ezt általában rendkívül gyakorlati - mindennapi munkámból vett - példák hétköznapi, az akadémiai életben kevésbé népszerű - php, javascript - nyelvekkel való megoldásán keresztül mutatom be.

A mai post ennél picit elméletibb. Én szeretném, ha ez egy kis vitát generálna köztetek, köztünk, így, író-olvasó között, már úgy értve, hogy a blogpostot mégiscsak én írtam, a kommenteket, visszajelzéseket meg majd reméljük, mások.

A Software Crisis arról szól, hogy a projektek 60%-a nem készül el időre vagy költségkeretre. Ez egy folyamatosan létező probléma, nem csupán a korai informatikára igaz, mai napig velünk van.

Amiről a software crisis nem szól, hogy azok a szoftverek, amik a végén így-vagy-úgy elkészülnek, mennyire teszik elégedetté az ügyfelet. Nem árulok zsákbamacskát, a legtöbb esetben semennyire.

Lehet ezért az ügyfelet okolni, hisz nem tudja mit akar, mindig változtat úgyis… De az építészetben ugyanez a helyzet, mégse omlanak össze az épületek, és alapvetően lakható helyeket készítenek jobb - akár magyar - építészeink.

Lehet ezért a beosztott programozóinkat okolni, de hisz legtöbben főiskolát, egyetemet végeztek, de legalábbis elkezdték: az építészetben a végrehajtók sokkal kevesebb képzettséggel rendelkeznek; mégis, a házak állnak, még a középszerű mérnökök által tervezett, vezetett projektek végén is.

Szerintem a hiba bennünk van: senior programozókban, vezetőkben, projektmenedzserekben, architektekben, bennünk, akiknek hozzáértésünket, akadémiai ismereteinket, szakolvasmányainkat kéne hozzárakni tapasztalataink mellett a projektekhez.

(more…)

A mai post kicsit alapszintűbb, műegyetemi infoképzést őszintén végighallgatók sok újat nem fognak benne találni. Az apropója egy új, fiatal kolléga a csapatban, aki teljesen új modult fog kapni, és arról beszélgettünk, ehhez hogy kell nekilátni - szerintem.

A kezdő informatikus - vagy a nem kezdő, ugyanakkor más szemléletű vagy épp autodidakta - ha kap egy feladatot, mivel kezdi?

Az adatstruktúrák felállításával.

You’re doing it wrong. *

(* Legalábbis szerintem, a legtöbb esetben)

Egy programnál sohasem az a kérdés, hogy milyen elemek vannak, ez részletkérdés. Ami a fontosabb: mit kell csinálnia annak a szegény programnak?

Erről ad információt az (egyesek kedvéért huszonötször átnevezett, elrejtett, átsematizált) use case modellezés.

(more…)

(Kettő és feledik rész, linkajánló)

A tapasztalatom az, hogy a magyar programozók, ritka ám tiszteletreméltó kivételektől eltekintve, nem szeretik, nem is értik a javascriptet. A legtöbbje backend ember, jobban megbízik a statikus nyelvekben. Szíve joga.

Egy magyar srácot hallani beszélni arról, hogy hogy használják a javascriptet szerveroldali nyelvként, mennyivel biztonságosabb és skálázhatóbb(!) a javascript kód a javahoz képest, mennyivel egyszerűbb javascriptes embereket szerezni egyszerre meglepő és felemelő érzés.

A java számomra egyértelműen túl van értékelve. Persze nem azért szidom, mint mások, de ettől még nem mindig jó megoldás ott, ahol használják, és komoly problémák vannak vele nyelvi szinten is.

Hallgassátok hát Szegedi Attila előadását a Javascript üzenet-orientált banki rendszerükről az InfoQ-n.

A piramisokat négyezer éve építették.

Az elsők szétrepedtek, jónéhányan összedöltek.

Aztán néhány sikerült.

Majd mások megint nem.

De előbb-utóbb megtanultuk, mit kell tenni ahhoz, hogy megállják a helyüket.

Aztán a végére már elméletünk is volt mögötte.

A szép az, amikor már rutinból nem dőlnek be az épületeid, és azt is tudod, miért nem.

(Egy infomérnök vallomásai: régi draft az adamnemeth.hu -n)

Mostanában a munkámban egyre többet foglalkozom nagyléptékű tervezéssel ismét. Ennek minden szempontból örülök: beosztott kódernek sajnos soha nem voltam jó, és most se vagyok az, kényelmetlenül érzem magam benne, mint holmi szűk kabátban.

Az Architect dolgok ebbe kíván kis betekintést nyújtani. Szigorúan leendő és jelenlegi programozóknak.

I. rész: Logika és Struktúra, avagy Algoritmusok + Adatstruktúrák = Programok [1]

(more…)

Az iWiW új dizánja kapcsán került elő egy ismerősöm, az alábbi beszélgetés zajlott köztünk (rövidítve):

1:07:33 AM XY: kapcsolatban allsz az iwiw fejlesztokkel?
1:07:43 AM XY: kerlek add at nekik a kovetkezo kis uzenetet:
1:07:44 AM Aadaam: mondjuk
1:08:13 AM XY: “Kedves fejlesztok! Kerlek nezzetek meg a Facebook keresodobozat, utana masoljatok le vagy akasszatok fel magatokat. Koszonettel: XY”

(Természetesen nem ezt a módját választottam az információátadásnak, a postban nem erről lesz szó, sok egészséget, boldogságot minden általam ismert iWiW-közeli embernek - van belőlük pár)

Az illető történetesen informatikushallgató.

Némi csúnya visszaszólás után (azóta remélem, már kevésbé haragszik) összekötöttem Benjaminnal, és hozzávágtam a megfelelő technológiát: “Tessék, csináld meg!”

Hogy miért tettem és igazam volt-e (szerintem igen, különben nem tettem volna, a kommentsáv használata meg ismert , arról szól a post.

(more…)

avagy a válasz arra, miért is informatika, és mit csinál ez.

A most következő írássorozat inkább féllaikusoknak, és talán kevésbé a professzionális .NET C#, Java Enterprise, Xquery meg hasonló technológiákkal foglalkozóknak szól, de átfutásra érdemes. Tulajdonképpen bevezetőként szolgál a szemantikus web, mikroformátumok, mashupolhatóság, és egyéb informatikai témáknak, nehéz lenne enélkül megérteni a gyors alkalmazásfejlesztés és a szemantikus információkezelés lényegét.

• Első rész: Bevezetés: IT
• Második rész: Web

Az előző részekben az adatorientált rendszerek megfeleltetésével foglalkoztunk a tipikus mindennapi feladatokhoz. A most következő írás az algoritmusokat fogja boncolgatni, hiszen számítógépes program - egyelőre - nehezen képzelhető el nélkülük.
Hol a számítógép?

Kevesen tudják, de a BME-n - nem alaptalanul - úgy tanítják a programtervezést, hogy minden programnak valószínűleg kell lennie egy papíralapú (űrlapalapú) modelljének, különben valamit lehet, hogy elrontottunk. Értelemszerűen a BME-n kevésbé a játékfejlesztőket képzik, inkább az üzleti élet számára nevelnek informatikusokat. Felmerülhet a kérdés:

A számítógépnek tényleg csak az a feladata, hogy az információkat lehessen tárolni, azokon navigálni?

A válasz pedig egyértelműen nem - a számítógépnek ugyanis van legtöbbször egy moderátori szerepe.

(more…)

avagy a válasz arra, miért is informatika, és mit csinál ez.

A most következő írássorozat inkább féllaikusoknak, és talán kevésbé a professzionális .NET C#, Java Enterprise, Xquery meg hasonló technológiákkal foglalkozóknak szól, de átfutásra érdemes. Tulajdonképpen bevezetőként szolgál a szemantikus web, mikroformátumok, mashupolhatóság, és egyéb informatikai témáknak, nehéz lenne enélkül megérteni a gyors alkalmazásfejlesztés és a szemantikus információkezelés lényegét.

• Első rész: Bevezetés: IT

Az előző részben átfogó képet kaphattunk az informatika eredetéről, és az üzleti rendszerekkel szemben támasztott általános követelményekről. A mai generáció kevésbé szembesül közvetlenül ezekkel a programokkal, így jogos a kérdés:
Mi a helyzet a Web (2.0)-vel?

A weben a világ sokat egyszerűsödik. Ha jobban belegondolunk, egy weboldalon a lényeges információ jó része szöveg, amit már hamar megtanultunk struktúráltan kezelni; átvitele nem volt annyira nehézkes az informatika világába. Az eredeti webes elképzelésben a címeket, fejezetcímeket fejlécek, a bekezdéseket paragráfus-jelek jelezték, és csak két új dolgot vezettek be, az egyik a képi információ beágyazását, a másik pedig a navigálást (linkelést) tette lehetővé.

(more…)

avagy a válasz arra, miért is informatika, és mit csinál ez.

A most következő írássorozat inkább féllaikusoknak, és talán kevésbé a professzionális .NET C#, Java Enterprise, Xquery meg hasonló technológiákkal foglalkozóknak szól, de átfutásra érdemes. Tulajdonképpen bevezetőként szolgál a szemantikus web, mikroformátumok, mashupolhatóság, és egyéb informatikai témáknak, nehéz lenne enélkül megérteni a gyors alkalmazásfejlesztés és a szemantikus információkezelés lényegét.

Talán mindenkinek feltűnt már, hogy a napi betevő pornónkhoz internetünkhöz biza nem kell az a 2GHz-s processzor, ami mostanság ketyeg egy meglehetősen alsókategóriás gépben. Nem használunk ugyanis kezelhetetlen mennyiségű adatot: a videók esetén igen (nem fogja senki 15 másodperces blokkokban egy fényképből és mozgásvektorokból összerakni az egész estés torrentrevalót kézzel, megteszi ezt nekünk a legtöbb movie codec), de web esetén abszolút nem.

Ez azért van, mert információkkal dolgozunk, amik emberi léptékűek: weboldalak, táblázatok, word dokumentumok. A legnagyobb felismerés a huszadik században az lehetett, hogy az információnak formája van, sőt legtöbbször struktúrája.

(more…)