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…)

Avagy, lusta vagyok leveleket írni

A kedvenc karácsonyi dallamom a Carol of The Bells, másnéven Ukrainan Carol, abbol is Ray Conniff 1962-es feldolgozása:

Ugyanis olyasmit mond el, amit kevés karácsonyi dalban látok viszont.

Ez nem a meleg szobák éneke: ez a vidéké, a hideg télé, a bizonytalanságé, a félve kimondott reményé, a csakazértis Jézusé, amikor már csak kapaszkodóként is ezt énekled, mert bár Tudod, de bizonyos sose lehetsz benne teljes valójában földi léted során, mégha naponta tapasztalod is.

Ez az értékrendeddel ellentétes világban énekelt dallam, aminek része vagy, de mégse úgy jó itt amit jónak hívnak, ahogy szeretnéd, hogy jó legyen, a huszonegyedik századi mindennapok tapasztalata - és a huszadik századi Ukrajnáé is minden bizonnyal. De mégis, bár picit félve, kiállsz, és Jézusért kiáltasz.

Az eredetileg kora tavaszi szerencsekívánó versikét már abban az időben írta át Leontovics kórusművé, amikor Ukrajnában az újévet nem tavasszal, hanem január közepén ünnepelték, megmagyarázva ezzel az eredeti szöveg- és dallamvilág különbözőségét. Keresztény kontextusra és angol szövegre csak a 30-as években ültette át Peter Wilhousky.

Ezt a hangulatot adja vissza olyan jól a Connif-feldolgozás.

Az ukrán eredetit meg lehet hallgatni itt (Oleg Bulaschenko professzor oldaláról).

Ebben a playlistben pedig 3 kiváló feldolgozás szerepel egymás alatt, köztük egy cseh amatőr kvintett zseniális videója.

Mindenkinek Boldog Karácsonyt és - bár addig tervek szerint jelentkezünk - sikeres új évet!

Objektívan nézve a szavazásban ez nyert, így ez az első, de következőnek követi majd a tervezési folyamat. Kevésbé objektíven nézve a szavazószoftver az adblockereseknek jó eséllyel nem működött megfelelően (legalábbis kaptam erre utaló visszajelzéseket), de valami alapján dönteni kellett…

A requirement analysisnek (magyarul: megtudni, mit is kéne csinálni) a gyakorlatban két módja van:

• az egyiket már félig-meddig bemutattam, ez a use-case analízis. Ez egy lassú, de biztos módszer.
• A másik egy sajátos európai módszer: a klónozás. Ez általában nem is a programozókat érinti leginkább, hanem a megrendelőket: “egy olyat akarok, mint ez”.

(Hívják ezt kreatív másolásnak is…)

Ez utóbbi módszer megrendelői oldaláról egyszer elmondtam az őszinte véleményemet. Azóta több ember nem hajlandó velem szóbaállni; olyan se, aki részt se vett benne, csak klónozott terméket felügyel. Így most csak azzal foglalkozunk, a fejlesztés műszaki vezetőjeként mit tehetsz a szituációval.

A klónozás ugyanis egy dolgot nem mond meg: hogy mi miért van ott. Pont a legfontosabbat hagyja ki, azt, hogy mikre van szükség. Nem jó általában dolgozni olyan ügyféllel, akit nem lehet túllendíteni ezen.

De mégis, mit lehet tenni?

Ha előre nem megy, kénytelenek vagyunk visszafele.

(more…)

Az architect dolgok sorozatra több megoldásom is lett volna a héten, de sajnos időközben ideiglenesen lekorlátozódtak az energiáim.

Szeretnék azonban némi interakciót is, nem kell komment, kéne egyet szavazni. Remélem, jövő héten már jobban leszek, és akkor tudok tartalmat is mögérakni…

Témajavaslatok:

• Architect dolgok - mindless cloning, avagy, hogyan kell mérnöki módon kezelni azt, ha a specifikáció annyi “ugyanilyet szeretnék mint ez?”
• Architect dolgok - Közösségi webalkalmazás építése PHP alapokon, szépen - van elfekvőben egy jó minőségű kis symfonys kódom, közösségi (twitter,facebook, iwiw) appnak, nem túl sok, de sokmindent be lehet rajta mutatni, és senki felé nem licencköteles
• Architect dolgok - tervezési folyamatok - tovább folytatva az általános részt, rendszertervezési gyakorlat
• Egyéb - akkor kommentelj

A tarsolyban van még egy félkész játék JS-ben, opensocial okosságok, webes modultervezés (ami nem azonos a rendszertervvel), de ezek azok, amik előránthatóak könnyedén.

Nos, mit gondoltok?

(Alant egy poll-r szavazás, ha nem jelenne meg rss-ben)

Eddig megjelent architect cikkek:

• Architect dolgok - modellezés a gyakorlatban
• Architect dolgok - agilis projekt
• Architect dolgok - informatika elméletben és gyakorlatban
• Architect dolgok - Use case-ek, modellek, követelmények
• Architect dolgok - Ajánló: Javascript in the enterprise
• Architect dolgok - Framework napok alatt
• Architect dolgok - Logika és Struktúra

Sziasztok,

Sorozatunkat megszakítva, mert már annyian cseszegettek miatta:
1) A szájt fájlrendszere érintetlen
2) A szájt adatbázisához most nem tudok hozzáférni (Márk, hogy lehet?), de az is érintetlennek tűnik
3) Ha a feedURL-t betöltöd egy böngészőbe, helyes
4) Ha nem google readert használsz, helyes
5) A google readeres ismerőseim átlag felénél jó a szájt, másik felénél spam van.

Szóval nem tudom, mi a baja. Alternatív RSS-nek itt van Gazs feedje (kösz, Gazs!), illetve egy Yahoo Pipes feed, ezek mennek a birodalmi readerrel is.

Persze, frissítenem kéne wordpress-t, ez nem feltétlen pusztán lustaság okán nem történik meg…

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…)

A legutóbbi post után egyik olvasóm (feltéve, hogy több is van), arra kért, írjak az Agile módszerekről.

(Jövő héttől esküszöm, programozni fogunk. Suszter meg kaptafa, ugye.)

(Illetve lehet, hogy nem értek hozzá: viszont mi tudtunk határidőre is hozni dolgokat, nagyjából ezzel a készlettel. Azért ebben az iparban ez nem egyértelmű…)

A baj az, én nagyon rég vezettem projekteket, akkor is inkább vezetőfejlesztő voltam (úgy hívtam: szakmai / műszaki projektmenedzser), de leírhatom, hogy mik voltak az alapelveim a jó-hely és az azt megelőző projektek idején, és hogy látom most, akár az agilis módszertanok tükrében.

Itt szeretném halkan megjegyezni, biztos-ami-tuti, hogy ennek nem feltétlen van köze ahhoz, ahogy mostani munkahelyemen vezetnek projekteket, nem mintha nem csinálnának egy csomó dolgot nagyon jól, csak én ott fejlesztő vagyok, és nehogy valaki összekeverje.

(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.