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

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

Frameworköt írni nem egy nagy dolog.

Tulajdonképpen minden jó programozó tud frameworköt írni, és a legtöbbje ír is. Persze a Jó Programozó azt is tudja, más, mégjobb programozók írtak frameworköket, így ő, ha teheti, nem ír sajátot.

Mi nem tehettük meg: nincs sok PHP4 framework, és létező kódhoz kellett hozzáírnunk, természetesen egy szigorú security audit előtt (aminél jobb, ha nem a mi kódunk bukik meg.)

Mi is kell egy webes frameworkhöz?

Az “Architect dolgok” második része erről szól.

(more…)

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

Egy kis vallomással tartozom nektek:

Nem tudom, kész lesz-e a jó-hely wiwes változata március végére. Egyelőre sajnos úgy néz ki, hogy nem.

Ennek leginkább az oka, hogy nem tudtam megteremteni a körülményeket a fejlesztéshez. Hogy ez mennyire volt az én hibám vagy se, azt döntsétek el Ti a post végén (kommentben, tényleg, kérlek)

A post hosszú lesz, a következőkről lesz szó:

• A Jó-hely előtörténete
• A wiw opensociales indulása és a jó-hely
• A most kialakult helyzet

(more…)