Adam Nemeth’s Blog

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