Informatika oktatás

István írására egy komment...


Ezt csak összehasonlításként mondanám el, mert a középiskolai szintű oktatást én sem tartom alkalmasnak arra, hogy szoftverfejlesztőket képezzen.
Középiskolába infós szakra jártam, nekünk volt valamiyen tantárgy, ahol elmondták az összes rendezési algoritmust, kereséseket, és pl a backtrack algoritmust, ami rémesen egyszerű, majdnem primitív. Kb 20 perc alatt mondta el a tanár az órán ismétlésekkel együt, utánna mindenkinek kellett egy példafeladatot megoldania a backtrackkel (válaszhatsz labirintus vagy a 8 királynő közül), utánna mindenkinek ment, egymásnak is el tudtuk magyarázni, semmi nehézség.

Évekre meg is feledkeztem az egészről, egész addig amig be nem íratkoztam ELTE progmat esti tagozatára. Progmaton pedig Fóti tanárúr szánt rá az "Bevezetés a programozáshun" elméleti előadásokból egy egész estényit, az egész fejezetnek ez volt a címe, hogy "Backtrack". Absztrakt számrendszerekkel kezdte, aztám a korábban megismert állapotterekre fordította le a témát, majd végül felírta a backtrack csodálatos matematikai definícióját, alig 2 óra alatt. Eközben mindenki szorgosan jegyzetelt, de ráncolt homlokok és a ködös tekintetek mögött látszott, hogy az emberek egyetlen kérdése a témával kapcsolatban egy általános "WTF". Az előadás után néhány embert megkérdeztem, hogy hol vetnék be a backtrack algoritmust. A reakció volt érdekes, mert a legtöbb embernek nem esett le, hogy itt most valami olyat hallottunk, amit bármire is be lehetne vetni, páran mondták csak azt, hogy "hú, azt még nem tudom".

Ha ismered egyébként a "Bevezetés a programozáshól" 1-6 tárgyat, akkor ezen talán nem lepődsz meg. Sok vita tárgya, de azt hiszem a legtöbben egyetértenek abban, hogy a hétköznapi szoftverfejlesztés gyakorlatától távolabb áll, mint a művészettörténelem.

Végeztem még egy pár kisérletet, és egyébként informatikában és algoritmuselméletben nem jártas embereknek (például édesanyámnak) elmagyaráztam az algoritmust, nyilván nem írattam velük ZH-t vagy gyakorló programot, de megkérdeztem, hogy pl milyen feladatra lehetne ezt a módszert bevetni. A magyarázat kb 2 percet vett igénybe, és működött.

Tehát nem kalapácsot adnak a kezünkbe, hanem megtanítanak gondolkozni... Igen, látom hogy kalapács nincs, de gondokodni megtanultunk vajon? Vagy komplkálni tanultunk meg? Vagy az ugyanaz? Vagy csak hisszük, hogy ugyanaz? Vagy most mi van?

A gyakorlati téren, már amennyire van gyakorlati oldala az ELTE progmatnak, sokkal kiábrándítóbb tapasztalataim voltak. Például egy C++ zárthelyin a leadáskor kellett megpróbálnom elmagyarázni a tanárnak, hogy mi a unit teszt (a kérdésére, hogy mit lát a képernyőn). Feladta és elmenekült, de itt nem volt vége, a következő tanárnak azt kellett elmagyaráznom, mi a standard input stream. Ezt követően egyetértésben nullásra értékelték a ZH-mat, pedig addig nem mutattam jelét annak, hogy szivesen feldarabolnám a két barmot.

Nem ott és azonnal, de hasonló esetek sora lassan leamortizálta a türelmemet. Munkám nyilván volt már, egyébként nem tudtam volna kipengetni a tandíjat. A pénzt nem sajnálom, de az időmet nagyon.

De egyetértek Istvánnal: ha van rá pénzed, menjél egyetemre. Tanuld meg, felejtsd el! Ez egy jó gyakorlat. Mi mást csinálnál 18-19 évesen? :-)
Hajrá!

checklist project indításhoz

Pár dolgot összeírtam, amit az ember bán az egész projekt során hogy nem lett meg a legelején. Nem vagyok én se híve a sok pöcsölésnek, de ismeritek azt a mondást, hogy...

Néhány hét kemény munkával több órányi tervezést meg lehet takarítani.

Hát szóval...

Első helyezet: Adatbázis schema verziózás

Kár vitatkozni hogy, old school liquibase vagy az újabb flywaydb, a saját buherált script is csak ritkán rosszabb a semminél :)
Ezen már évek óta sokat bosszankodok, hogy hogyan lehet ilyet bénázni, de sok megörökölt projektemen egyszerűen totál másmilyen volt a teszt schema a prod schemához képest és az embereknek olyan ködös elképzeléseik voltak hogy "A DBA nem tudja másolni a teszt schemát amikor upgradelünk?"

Erős második: forráskód formázó beállítások

Csodálatos módon az eclipse és az intellij értik egymás kódformázó beállításait. Pontosabban az intellij érti az eclipse-t, az eclipse meg jobbára érti önmagát.
Annyi tennivaló marad, hogy azokat az igazhitű junixereket, akik vimmel meg emacs-szel akarnak szoftvert fejleszteni, szóval őket egy tompa nehéz tárgyal jobb belátásra téríteni.
Aztán még a space-nácik és az alternatív tab-pártiak összecsapását is gyorsan helyre kell tenni, de ehhez a tompa nehéz tárgy helyett inkább valami gyorsan használhatót ajánlanék, pl lángszóró.

Bronzérem: CI enforce tests

Amikor már fél éve törött egy teszt és senkit nem érdekelt, így ment élesbe akkor már igazán késő sajnálkozni.
Persze mostanában dolgoztam olyan kollágával is, aki eltörte a tesztet és írt egy levelet, hogy "a junit teszt nem működik, javítsd már meg" Ezek ilyen kultúrális kompatibilitási problémák.

Negyedik: DEV produktívítás

Szerintem érdemes valami egyezségre jutni, vagy megpróbálni egyezségre jutni, hogy milyen eszközöket használunk és azokkal mekkora overhead-et kap az egész fejlesztés. Amikor egy tool már bent van, akkor már késő, az többnyire ott marad.
Pl hogy beéred-e egy gyors jetty-vel a fejlesztőkörnyezetben vagy muszáj legyen megvárni, hogy a websphere felemelje a seggét, esetleg elég ha a tesz környezet websphere...
Hogyan bánjunk a ránk kényszerített közös MQ-val, közös adatbázissal.

Ezeknél szokott elcsesződni a produktívítás, amikor hosszú perceket várhatsz egy buildre. Vagy pl sokan másolgatnak fileokat a dev folder és a webszerver között. Ez nekem már 2000-ben is a rühes 90-es évek maradványának tűnt.

5: contact list

Egy egész sor projecten dolgoztam úgy, hogy vakon mentünk. Fogalmunk sem volt, hogy ki a felhasználó, ki a DBA, ki fogja a support feladatokat ellátni, és nyilván hogy ők hogyan szeretnének velünk együt dolgozni. Egy ilyennel garantált a későbbi probléma.

Biztos van még sok, csak most nem jut eszembe, legyen akkor csak ennyi most.