ugrás a tartalomhoz

After all! What is this no-framework?

Joó Ádám · 2010. Jan. 4. (H), 13.23
Hogyan dolgozzunk keretrendszerek nélkül?
 ■
1

A cikk maga (szvsz) bullshit kategória

Thoer · 2010. Jan. 5. (K), 01.42
és erre az első hozzászólás tökéletesen világít rá. A keretrendszerek lényege, hogy jól dokumentált, az igényeinknek megfelelő, más fejlesztők számára is átlátható alapot használjunk a megvalósítandó feladathoz. A szerző válaszának (második komment) már több értelme van, de jelzi, hogy eléggé limitált lehet az ismerete a php keretrendszereket illetően. Úgy érzem jó eséllyel belefutott párba, ami pont nem tetszett neki a cikkben részletezett okokból (tippem: CodeIgniter, CakePHP, Symfony) és levonta azt a hibás következtetést, hogy minden keretrendszer ilyen. Ehhez képest mondjuk a Zend pont nem kényszerít rá semmit, még az MVC-t se. Hozzáteszem én a cikk pontjaival sem értek egyet.

Nem mellesleg szerintem a szerző nem alkotott még tökéletes képet az MVC mibenlétéről sem, de legalábbis elég egyedi és számomra ijesztő elképzelést vázolt a felsorolás második pontjában...
2

egyetértek

virág · 2010. Jan. 5. (K), 10.46
Teljesen egyetértek veled.
3

Csak átfutottam

Max Logan · 2010. Jan. 5. (K), 11.17
Ami nekem még mindig nem tiszta, hogy miért ragaszkodik mindenki az általánosított keretrendszerekhez (persze, csapatban gondolkodva értem a lényeget)?

Ennyire nehezen tudjátok elképzelni a célspecifikus programozást?

És azt, hogy egy programot csak egy ember tart karban?
6

Ennyire nehezen tudjátok

Török Gábor · 2010. Jan. 5. (K), 13.34
Ennyire nehezen tudjátok elképzelni a célspecifikus programozást?

Nincs olyan program, aminek az oroszlán részét már ne írták volna meg előtted. Az miért baj, ha ahelyett, hogy újra és újra lekódolod azt, amit, tesztelt és rugalmas keretrendszerben dolgozol? Minden program célspecifikus, a keretrendszer speciális célja, hogy általános felületet kínáljon. A keretrendszerek a bevált tervezési, fejlesztési mintákat kínálják neked. Ezzel nem akarsz élni? Hovatovább a saját kis rendszeredben felhalmozott tudást kinek tudod odaadni? A haverodnak, aki szintén a saját célspecifikus programját írja? A tudásmegosztástól eleve elzárod magad.

És azt, hogy egy programot csak egy ember tart karban?

Meddig? Amíg el nem mész a cégedtől vagy amíg a fejedben van az, amit két hete kódoltál. És két év múlva?
10

Re

Max Logan · 2010. Jan. 5. (K), 15.51
Megírták előttem. Ok, Swiftmailer-t használok, de ettől függetlenül mondjuk én akarom eldönteni, hogy milyen formában valósítok meg egy egyszerű MVC rendszert. Nem akarok komplex, mindenre kihegyezett rendszert használni, amikor én olyan munkákon dolgozom, amihez erre nem (feltétlenül) van szükség.

Ami a tervezési mintákat illeti, amíg az ember nem ismeri meg, addig a gyakorlatban sem feltétlül tud egy implementációval hatékonyan dolgozni. Meg én szeretem magam felépíteni a dolgokat. Van egyszerű, egy oszályos template megoldásom. Az én igényeimnek megfelel, én írtam, tudom, hogy mit tud, mit tudok kihozni belőle. Ha előáll egy újabb igény, tudom, hogy merre lépjek.

Ezt értem célspecifikus programozás alatt. Célspecifikusan fejlesztem a tudásom, nem karrierista szemléletben. Csak arra felé indulok amire szükségem van, nem indulok el egy irányba, nem teszek szert nagy területet lefedő tudáshalmazra (persze szerteágazó ismeretek gyűjtök, de nem leszek naggyon jó mindenben; mert ilyen nincsen, mert igazából nem jó irány). Egyszerűen, mert nem ilyen karrierben, hanem célspecifikus megoldásokban gondolkodom, ilyen munkákat csinálok.

Ha cégnek dolgozom, akkor távlatokban gondolkodom, a tudásom átadom másnak (gazdagon kommentelt kód, a munka ideális esetben funkciónális specifikáció alapján indul, ha kell akkor készül megvalósítási terv, stb, stb.). De pont erre írtam, hogy annyira elképzelhetetlen, hogy hosszabb távú munkakapcsolatban van a fejlesztő és megrendelő? Nem mindenki gondolkodik karrierben, nem mindenki akar egy kis garázscégből a Google-höz fejlesztőnek elszegődni. Ennek fényében éveken keresztül egy ember dolgozik egy-egy programon, rendszeren. Vannak mesteremberek is, én ezt a szemléletet képviselem. Nem egy "droid" akarok lenni a nagyok háta mögött.

Meg az én hozzáállásom nem a pénzorientált, kapitalista hozzáállást erőlteti, hanem a manufakturális, kisléptékű, célspecifikus hozzáállást, emberközeli hozzáállást.

Nem tudok jobb példát hozni, mint amit számtalanszor megemlítek. Vannak konfekciós öltönyök (kész keretrendszerek), amit lehet alakítani, de sosem lesz olyan, mint egy személyre, méretre szabott öltöny (ezt értem én célspecifikus megoldás alatt én ilyet készítek és az életben az ilyen megoldásokat keresem, nem érdekelnek a tömegtermékek -- minden mester attól lesz mesterember, hogy saját, jól bevált metodikákat alkalmaz).


Ui.: Megnéztem már több ilyen rendszert, vettem is ötleteket belőlük, de az én rendszeremet én akarom felépíteni. Ha meg átt kell építeni egy Symfony-t egy komolyabb projekt miatt, akkor pedig megítélésem szerint inkább jobb a nulláról felhúzni az egészet. Itt most nem nézek pénz, idő faktorokat, az összetett kérdés.

Gyakorlatból tudom, hogy van olyan, hogy egy általánosított program foltozására, átszabására nagyságrendileg több lóvét költ egy cég, mintha a nulláról megiratott volna egy saját magára szobott célspecifikus programot.
7

Mit értesz célspecifikus programozás alatt?

Thoer · 2010. Jan. 5. (K), 13.52
Jön egy új projekt én meg nyitok egy index.php-t és elkezdek mindent megírni?

A modern keretrendszerek három dolgot tudnak, szerintem mindegyik fontos.

1. Kialakítanak egy jó struktúrát a létrehozandó programnak (tipikusan MVC valamilyen továbbfejlesztéssel) Ez nekem tökre megúszhatatlannak tűnik egy átgondolt szoftver esetén. Persze tömegével látni még mindig olyan szoftvereket, hogy minden funkció be van vágva egy külön php fájlba, a lényeges részek meg copy-paste alapon ott figyelnek az összesben, kezdve az adatbázis-kapcsolattól az analytics javascript kódjáig minden, de ezek az uramisten kategórába tartoznak. (Hemzsegnek a biztonsági hibáktól, átláthatatlanok és karbantarthatatlanok.) Tehát miért is lenne jobb ha én hoznám létre a struktúrát egyesével egy másolás vagy parancssori parancs kiadása helyett?

2. Adnak egy sor hasznos modult, osztályt, függvényt. Ha akarom használom őket, ha nem akarom, akkor meg nem. Mi szól ebben ellenük?

3. Jól dokumentáltak, a belső keretrendszerek és főleg a saját (egyszemélyes) rendszerek sosem veszik fel ebben velük a versenyt. Tisztelet persze a kivételnek, de mondhatjuk úgy is, hogy ha a belsős rendszer is olyan dokumentált lenne, akkor is megspórolják a nyílt rendszerek a dokumentálás nyűgjét.

Az egyetlen érv ellenük szerintem az a többlet forrásigény. Akit viszont ez nagyon zavar, az azért talál olyan minimalista rendszert is, aminek az overheadjét problémaként értelmezni nem mérnöki szemléletet, hanem szőrszálhasogatást tükröz.
8

Re

Max Logan · 2010. Jan. 5. (K), 15.30
Az a baj szerintem, hogy akik itt komolyabb tudás birtokában vannak és komolyabb rendszereket fejlesztenek már nem tudnak kicsiben gondolkodni.

Egy egyszerű, kisebb céges honlap esetében minek használjak pl. egy komplex Symfony-t, amikor az én saját egyszerű rendszeremmel is meg tudom oldani jelentősen kisebb kódállománnyal.

Dokumentáltság kérdése. Megint csak az előző kicsiben gondolkodásra tudok utalni. Ha jól dokumentált, akkor valószínű, hogy jelentősen bonyolúlt, kis feladatokra (pl. cron script) nem éppen célszerű a használata.
12

Téves következtetés

Thoer · 2010. Jan. 5. (K), 16.39
Ebből a szempontból két féle honlap van: amihez kell szerver oldali programozás (~99.9%) és amihez nem (~0.1%). Ha kell, akkor miért kell? Majdnem biztos, hogy minimum fel kell dolgozni valamilyen űrlapot. Mit jelent ez?
  • Meg kell vizsgálni, hogy megfelelő adatokat kapunk-e
  • jelezni kell az esetleges hibákat
  • elvégezni átalakításokat, hogy el tudjuk menteni az adatbázisba és/vagy tudjuk küldeni levélben, illetve vissza tudjuk írni a nem hibás adatokat
  • el kell végezni az adatbázis műveletet / levélküldést / űrlap kiírást

Egy ilyen komolyságú művelethez már komoly előnyöket nyújtanak a keretrendszerek:
  • Komplett, jól olvasható validálást végeznek, a többség egy beállítással rögtön a megvéd az XSS jellegű támadásoktól. Nem csak arról van szó, hogy ezek jobb megvalósítások általában, mint amit a mezei programozó egyedül összehoz, hanem az automatizmus kényelmet és biztonságot is ad! Ráadásul ha csak ezt az egyet veszed, ha nem akarod ezerszer ugyanazt megírni, akkor minimum a saját moduljaidat fogod használni és jó eséllyel elindulsz a keretrendszer használat felé. Épp csak azzal a különbséggel, hogy ezt csak te ismered, jó eséllyel kevésbé is lesz komplett, mint amit sokan használnak. Ráadásul ha egyszer más veszi át a fejlesztést vagy sok idő után kell visszanyúlnod, akkor előjön a dokumentáltság kérdése is...
  • Az átalakításokra is sokszor kapunk eszközöket, de ha nem, egy jó keretrendszer arra is jó útmutatást ad, hogy hogy tudjuk kényelmesen hozzáadni a saját eszközeinket.
  • Az adatbázis piszkálása nem szokott nehezebb feladat lenni, mint egy SQL string megalkotása, viszont mindjárt megoldják az SQL injection problémák javát.
  • Az űrlap legrosszabb esetben is annyi munka, mintha magad csinálnád, de az űrlap segítő függvények is nagyon hasznosak tudnak lenni. Egy egyszerű alapértelmezett érték kontra korábban beírt (de el nem fogadott) érték probléma is sokszor meghaladja a fejlesztők képességét vagy épp türelmét. És akkor azt még meg sem említettem, hogy például egy Doctrine + Symfony kombinációval jószerivel elég csak az adatbázis sémát megadni a rendszernek, utána mind a tényleges adatbázist, mind az űrlapokat önmaga létrehozza a rendszer, ezáltal töredékére csökkentve a fejlesztési időt. Plusz egy alapértelmezett beállítás segítségével a CSRF védelem is meg van oldva!
  • mail függvénnyel is kevesen küldenek levelet, főleg UTF-8 kódolású HTML levelet, nem hiszem, hogy magyarázni kell, hogy miért.


Ehhez még vegyük hozzá, hogy a legtöbb keretrendszer segítséget ad az optimalizációhoz is (profiler, error handling, cache), és a teszteléshez is minimum útmutatást ad. Ezen felül kész modulok állnak készenlétben arra az esetre, ha az egyszerű oldal idővel bonyolódna.

A dokumentáltság és a bonyolultság között szerintem semmilyen összefüggés nincs, de hogy baj nem lehet, az biztos.

Emellett ha ismered az adott keretrendszert, akkor többnyire 10, legrosszabb esetben 30 percet vesz igénybe a telepítésük és kezdő konfigurációjuk együtt, de ebben már benne van a fejlesztői, teszt és éles környezetek beállítása is, hogy utána már csak fel kelljen tölteni a szoftvert... Ha további beállításra van szükség, akkor rendszerint órákat, de inkább napokat spórolsz meg 1-1 5 perces beállítással. (Ahhoz képest, mintha neked kellene fejleszteni a beállításnak megfelelő szoftverrészt.)

A cron script megjegyzést sem értem. Az semmi más mint egy action egy MVC rendszerben, maximum view nem kell...
14

Re

Max Logan · 2010. Jan. 5. (K), 17.14
Most csak a scron scriptre reagálok, a többit majd este.

Értem én, hogy csak egy action (nálam nem, mert éppen ezt mondom, hogy célspecifikus kódot írok, a cron script az nálam nem egy action, mert nem feltétlenül akarom a nagyobb project részeként kezelni a cron scriptet), de minek betölteni egy symfony egész feldolgozó rendszerét, mikor nekem elég egy, max. két fájl és már ott a saját kis MVC core-om (db layer-rel együt), ami éppen elegendő alap esetben egy cron scripthez.

Ha kell még egy mailer, akkor a SwiftMailer esetén már be kell húzni egy rakat fájlt (include csak egy de tölti automatikusan a többit), amit én pl. nem feltétlen szeretnék (mert csak).

Ha nem kell, akkor feleslegesen nem indítok egy mostrumot egy ilyen feladatra. Jobban szeretném, ha a SwiftMailer esetében lenne egy olyan cucc, ami egy db fájl és kész, nem egy rahedli "nagy", összetett fájlstruktúra. Mert én nem szeretem, ha egy ilyen "modul" egy ilyen feleslegesen összetett struktúrában terül el az én rendszeremben.
16

Elképzelhető, hogy létezik olyan feladat

Thoer · 2010. Jan. 5. (K), 17.47
ahol ez igaz is, de csak olyan eset lehet, amikor olyan gyakran kell futnia szkriptnek, hogy az már komolyan latba nyom a kapacitások kihasználtságában, de nem olyan bonyolult az elvégzendő feladat, hogy érdemes legyen beizzítani a teljes rendszert. Most hirtelen nem tudok ilyen szituációt elképzelni. Ha csak annyi haszon van a modul szoftverbe ágyazásának (->action), hogy nem kell külön karbantartani az egyes futási környezetek beállításait, akkor már érdemes lehet megtenni egy ritkán futó szkriptnél is szerintem...
17

Elvi megközelítés

Max Logan · 2010. Jan. 5. (K), 18.18
Mint lentebb írtam, nem a programozásból akarok megélni hosszútávon, így nem ultraszuper megoldásokat akarok kifejleszteni (azt megteszik a tényleg kocka, karrieristva vagy elvből programozó ), hanem számomra elvi megközelítéseket akarok adaptálni. Az én saját szájam íze, logikája alapján akarok rendszerek felépíteni. Ez olyan, mint amikor az ember elkezd építeni egy vitorlást. Lehet azt ötmillió módon, a lényeg, hogy csináld és olyan legyen, amilyennek te akarok. Vannak hajógyárak, de az egészen más kategória, más a cél.
4

ennél azért árnyaltabb a kép

Sulik Szabolcs · 2010. Jan. 5. (K), 11.39
A szerző inkább arra próbál rámutatni, hogy minél "kényelmesebb" környezetet biztosít egy keretrendszer, annál nagyobb energiával jár a rendszer megtanulása, lehetőségeinek átlátása. A felhozott példái kissé riasztóak persze, de a mondanivalójára érdemes odafigyelni.

Az elsődleges problémája a következő. Terry Chay szerint "writing software is about making choices. (choices have consequences.)", tehát ha (külső) keretrendszer használsz (tök mindegy, hogy cake, symfony, ci vagy zf) a döntések jó részét már meghozták helyetted, neked alkalmazkodni kell. Ez sokszor azzal jár, hogy nem is azon gondolkozol, mit hogyan valósíts meg, hanem, hogy hova is lehetne betuszkolni a választott architekturába. Itt persze jól jön, ha a rendszer rugalmas. Csak a tapasztalat azt mutatja, hogy a (nagyra nőtt) rendszerek tudják, amit kell(ene) csak a felhasználói (fejlesztők) nem ismerik pont azt a lehetőséget benne (tudom, ez nem technikai probléma :)). Ez is egy szempont.

Ami biztos, valamilyen fejlesztési keretre szükség van. Hogy a belső fejlesztés vagy egy külső rendszer a jó megoldás, az mindig szituáció függő.
5

Erről azt gondolom

Thoer · 2010. Jan. 5. (K), 13.20
hogy egy vezető fejlesztő igenis ismerje a legelterjedtebb keretrendszereket legalább egy olyan szintig, hogy képet tudjon alkotni a benne rejlő lehetőségekről, meg tudja különböztetni egyiket a másiktól, tisztában legyen a várható tanulhatóságról, elterjedtségről és dokumentáltságról. Ha ez megvan, nem igaz, hogy nem tud az adott projekthez legjobban használható alapot és modulokat válogatni. Ugyan mi akadályoz meg valakit abban, hogy egy Kohanára épülő szoftverhez a Zend APC modulját használja PHPMailerrel és Doctrine ORM-mel? A világon semmi szerintem. És azt se hiszem el, hogy ugyanannyi idő alatt lefejleszti a saját verzióáját, mint amennyi idő alatt egy-két-három új feature megvan bármelyik modulhoz még úgy sem, hogy az eredeti rendszerbe is bele kell integrálni.

Aki meg nincs vezető fejlesztői szinten, az jó esetben vagy egy vezető fejlesztő alá tartozik vagy úgysem kap olyan feladatot, hogy a NASA űrhajóit irányítsa a szoftver...
9

Ha ez megvan, nem igaz, hogy

Sulik Szabolcs · 2010. Jan. 5. (K), 15.50
Ha ez megvan, nem igaz, hogy nem tud az adott projekthez legjobban használható alapot és modulokat válogatni.


Ez rendben van, csak nem a vezetőfejlesztő fogja megírni a kód nagy részét. Nem ő lesz a leggyengébb láncszem.

...szoftverhez a Zend APC modulját használja PHPMailerrel és Doctrine ORM-mel...


Én pusztán a keretrendszerekről írtam, nem mindenféle libekről, amit fejlesztés közben használ(hat)sz. :)

...És azt se hiszem el, hogy ugyanannyi idő alatt lefejleszti a saját verzióáját...


Azt nem mondtam, hogy gyorsabb. Csak néha nem árt elgondolkozni, hogy valóban mire is van szükséged.

Félreértés ne essek, nem vagyok keretrendszer ellenes, mindig használtam (az utóbbi években gyakorlatilag symfony). Csak érdemes látni, hogy vannak bizonyos esetek, amikor az érvek a (külső oss) keretrendszerek ellen szólnak.
11

3 részre 3 válasz

Thoer · 2010. Jan. 5. (K), 16.34
1. Ez így van, viszont az előbb a döntés szabadságáról beszéltünk, márpedig egy kezdő programozó ne hozzon ilyen jellegű döntéseket! Viszont az is biztos, hogy szívesebben vennék fel magam mellé Symfony fejlesztésre valakit, aki legalább CodeIgniterben létrehozott egy Hello Worldöt, mint egy 8 éves tapasztalattal rendelkező spagettihuszárt.

2. Én meg azt mondom, hogy a döntések nagy részét nem hozták meg helyettem, hiszen én döntöm el, hogy milyen keretrendszert használok alapnak és milyen modulokat teszek a rendszerbe. Például a Zend elemeit közismerten bármelyik másik keretrendszer tudja használni, de a többit is php-ban írták, kevés kivétellel könnyen portolhatóak, ráadásul a komoly problémákra önálló könyvtárak is vannak szép számmal...

3. A cikket most nincs időm elolvasni, de a Max Logannak írt válaszom szerintem ide is vonatkozik. Mi a keretrendszer? Egy fájlstruktúra, ami megúszhatatlan, plusz egy nagy rakás használható vagy eldobható, azonos Coding Standardal készült kiegészítés.. Érdemes meggondolni, hogy az óriási Symfony helyett elég-e egy Kohana 2.x vagy valami még minimalistább szoftver? Igen, érdemes. Ha valaki úgy érzi, hogy tud még gyorsabbat írni és neki meg is éri a fáradságot, hát hajrá! Keretrendszert akkor is fog használni, maximum nem fogja tudni a nevét... :)

Viszont inkább egy akármilyen MVC szerű keretrendszer, mint még egy spagetti-szoftver!
13

Re

Max Logan · 2010. Jan. 5. (K), 17.09
Az első pontnál ott van amit fentebb írtam. Miért feltételezzük, hogy mindenki másnak a keze alatt dolgozik? Ennyire elképzelhetetlen egy hosszú távon munkálkodó, "mesterember"? Miért gondolkodik mindeki csak karrier üzemmódban?

A harmadik ponthoz pedig megint egy olyan gondolat, hogy attól, hogy valaki nem sorakozik fel egy nagy keretrendszerhez, attól miért spagettihuszár? Nekem is MVC rendszerem van. Azért jött létre, mert éppen a spagettikódtól akartam megszabadulni, valamint jobban akartam struktúrálni a kódot. És itt jön az, hogy én akarom eldönteni, hogy milyen modulokat milyen fájlokban tárolok, miképpen valósítok meg egy MVC logikát.

Nem vitatom a nagy keretrendszerek létjogosultságát, csak vannak más megoldások is. Nem mindenkinek kellenek, mert van aki szereti járni a saját útját, a saját kis rendszerén keresztül fejlődni.

Olyan, hogy tökéletes meg nem létezik ...
15

Saját framework is framework

Thoer · 2010. Jan. 5. (K), 17.35
Itt most nem volt szó óriási keretrendszerekről, Symfonyt kár emlegetni, mert az ugyan egy kiváló rendszer, de talán egyben a legnagyobb is, már ami a többlet-igényt illeti. Ugyanakkor lennének kétségeim, hogy a saját rendszered hozza-e azt a szintet, amit a kiforrott rendszerek. Ha igen, miért nem osztod meg őket másokkal, miért nem szerzel magadnak nevet ezzel? Hosszú távon csak jól járhatnál vele...
18

Re

Max Logan · 2010. Jan. 5. (K), 18.28
Miért nem szerzek ezzel nevet? Nagyon egyszerű. Az múlt év és az idei év történései alapján egyértelművé vált, hogy a programozást imádom, az életem része marad mindig is, de nem erre akarom alapozni a jövőmet.

Tavaj tavasszal még az volt tervben, hogy komolyabb karriert építek, de aztán az apró dolgokat összerakva rájöttem, hogy sokkal inkább a legkedveltebb hobbim, mint az életem értelme.

Amivel én majd nevet akarok magamnak szerezni, annak csak részben van köze a WEB-hez és a WEB inkább csak platform lesz, mint munkaeszköz (azaz, a majdani ötleteimet nem én fogom programozni).

Ebből következően a saját utamat járom (eddig is azt jártam, az élet minden területén).

Mint írtam a célspecifikus (azt tudja amit kell, úgy ahogyan kell és se többet, se kevesebbet) megoldások híve vagyok (nem csak a programozás, hanem minden téren), ezért nem akarok kiforrott, általánosan alkalmazható megoldásokat előállítani, mert ebben nem hiszek (ezért is zárkózom el elvből a CMS-ektől) -- és mint írtam, van most is egy olyan élő példa, hogy 10-15 millióba kerül egy vállalatirányítási rendszer foltozása, avagy egy általánosított rendszer megerőszakolása (ez itteni környezetben a Drupal például); ennyiből már olyan specifikus programot lehetett volna írni, ami megszólal és tényleg úgy műkdöik ahogyan kellene, kompromisszumok nélkül.



Összetett dolog ez egyébént. Amit itt vázolok hozzáállást, az csak egy része annak, ahogyan én látom az életet, a világot. Én szembefordulok bizonyos dolgokkal (mint pl. a pénz mértéktelen hajszolása, stb). Ami a név megszerzését illeti. Én annak sokkal jobban örülök, ha egy kevésbé profi (és itt az ultrkocka és a hobbikocka közti különbséget kell érteni) megoldással emberi értéket termetek, mintha 50x annyi pénzt hozok egy cégnek.

(Egy kicsit más téma. Egy-két hónapja egy embert elvittem a tőlünk kb. 7 km-re lévő faluba autóval. Jött a nagyvárosból (aka. 'pest), és a szomszéd faluba igyekezett stoppal. Elvittem saját költségen. Egyszerűn jól esett valami igazán emberit tenni, még akkor is, ha ez nekem forintálisan mínuszos volt.)
25

+1

zzrek · 2010. Jan. 5. (K), 21.19
Én is hasonlóan gondolkodom (a programozásról, a manufakturális/önálló munkavégzésről, a világról, a pénzhajhászásról, a stopposokról és valószínűleg a családról is).
Hozzátenném még, hogy programozás közben inkább élvezem azt, ha frappáns megoldásra jutok magam erejéből saját ötletem és tapasztalataim alapján, mint azt, ha más által kidolgozott eljárásokhoz, keretrendszerekhez kell alkalmazkodnom. Azért szeretek programozni mert élvezetet találok benne, nem azért mert pénzt hoz, pláne nem azért mert mások eldirigálják nekem hogy hogyan csináljam. (Ez persze nem jelenti azt, hogy mások bevált módszereit, hasznos tanácsait, eredményeit nem tartom nagyra, és nem igyekszem megismerni). Szóval számomra jobban megéri elgondolkodni valamin, csiszolgatni-fényesítgetni, mint profi, ám követő módon "végrehajtani".
Úgy gondolom, hogy kétféle ember van: a követő és az alkotó, és én ez utóbbi csoportba szeretek tartozni, mert bár ez rögösebb, de izgalmasabb.
27

Szívemből szóltál

Max Logan · 2010. Jan. 5. (K), 21.38
Jó látni, hogy nem vagyok egyedül a nézeteimmel ;-)
36

Úgy gondolom, hogy kétféle

hector · 2010. Jan. 7. (Cs), 22.48
Úgy gondolom, hogy kétféle ember van: a követő és az alkotó

Szerintem a két dolog nem zárja ki egymást. Én például mostanában tervezem beszállni az általam sokat használt Doctrine és a Zend Framework fejlesztésébe. Eleinte persze csak kisebb bug reportokkal, később akár nagyobb volumenű kódokkal és koncepciókkal. Úgy érzem többet tanulhatok azzal, ha együtt dolgozom hozzáértő emberekkel, és közösen alkotunk valami jót, mintha a sarokban ülve reszelgetném a saját kis fejlesztésemet (mondjuk annak is megvan a maga bája, ezt elismerem). Béke.
37

OFF: úgy gondolom kétféle

laco · 2010. Jan. 8. (P), 00.21
OFF:
úgy gondolom kétféle ember van:

az olyanok aki szereti beskatulyázni az embereket, és az olyanok akik tudják, hogy a világ nem csak fekete és fehér, hanem színes. :D
38

hát ja

zzrek · 2010. Jan. 8. (P), 12.32
... és vannak olyan emberek is, akik a mondanivalót nem annyira akarják megérteni, hanem inkább kifogásolni szeretik. (Értsd: nem beskatulyázni akartam az embereket természetesen és nem állítottam, hogy nincs átmenet a kettő közt, hanem érzékeltetni akartam a hozzáállás különbségét, amit legegyszerűbben úgy szokás, ha megmutatod a végleteket. Légyszi ne skatulyázz be olyan embernek, aki mindenkit beskatulyáz, köszönöm.)
19

Örökzöld téma a framework -

laco · 2010. Jan. 5. (K), 18.39
Örökzöld téma a framework - noframework :)

Én nem vagyok hajlandó egyetlen PHP framework-öt sem használni, igaz PHP-t sem. hehehehe
20

Max Logannek

Thoer · 2010. Jan. 5. (K), 18.57
Azt hiszem a félreértést nagyon jól mutatja az öltönyös példád. Egész pontosan abban, hogy maga a példa nem túl jó. A szoftver fejlesztés sokkal közelebb áll mondjuk a kerékpár gyártáshoz. A legtöbb ember bemegy a boltba és megveszi Kora-gazdaságos kerékpárt, akkor is ha a pénztárnál látja, hogy egy másik vásárló most vitt vissza két példányt letört hajtókarral. (Saját szememmel láttam!)

Ugyanakkor ha az ember komolyan gondolja a dolgot, mert ő vagy az ügyfele pénzt akar csinálni vele, akkor eldönti, hogy versenybiciklire (pl. Kohana) vagy terepbringára van szüksége (pl. Zend, Symfony) ami kicsit lassabb, de elmegy mindenhol. Megveszi az alap bringát elérhető de drágább áron (tanulási idő), cserébe sokkal jobb minőséget kap, és utána a tényleges igényei szerint elkezdi fejlesztgetni.

Mi itt jobbára azon vitatkozunk, hogy mik a legjobb technikák (best practice) a kerékpár súlycsökkentésére, vagy épp merevítésére, illetve, hogy melyik a legjobb kerékpár amire építeni lehet, te pedig abból indulsz ki, hogy ki készíti azt el és azt állítod, hogy amit te csinálsz az jobb lesz. Pedig ez messze nem biztos, sőt többnyire nem igaz. Ettől te még megteheted, főleg ha nem ebből akarsz megélni, de nem biztos, hogy érdemes.

Még ez a példa is sántít abban, hogy egy biciklihez ritkán van szükség dokumentációra. Vegyük a te esetedet! Azt mondod, hogy nem akarsz közvetlen programozásból élni, a web csak platform lesz. Rendben, gondolom akkor van egy nagyszerű ötleted ami majd termeli a pénzt, te pedig levezényled a megvalósítást. A nagyszerű ötletek többségét sok energia megvalósítani. Ha a tied pont nem, akkor sorry, de ez az eset a ritkább, ebben gondolom egyetértünk.
Tehát mint menedzser 1 programozóra bízol mindent és kivárod azt a hosszú időt amíg lefejleszti, vagy inkább megtöbbszörözöd a munkaerőt és elvárod az arányosan gyorsabb megvalósítást? Ha előbbi, akkor nagy valószínűséggel mire elkészülsz, addigra valaki meg fog előzni. Ha utóbbi, akkor óriási előny, ha a csapatod már eleve ismeri az alapokat (a keretrendszert) és ugyanígy fontos lesz, hogy a programozóid lecserélhetőek legyenek, ehhez pedig óriási segítség a jól dokumentált szoftver és kódolási standardok ismerete.

Persze nem vitatom, hogy vannak páran a világon, akik mondjuk - visszatérve a kerékpár analógiához - nagyszerűen megélnek Velocipédek gyártásából/hajtásából és nekik nem feltétlen számítanak a legjobb technikák, de ez csak kivétel lehet. Olyanok is lehetnek páran, akik úgy készítenek versenybiciklit, hogy maguk megtalálják a legjobb anyagokat és formákat, de gyanítom nem sokan és pláne nem biztos, hogy gazdaságosan is teszik azt!
21

Re

Max Logan · 2010. Jan. 5. (K), 19.30
A kerékpáros példád egyész jó, maradjunk ennél. Én abban hiszek, ha igazán jó bringát akarok faragni, akkor nem veszek meg egyet 1,5 milláért és költök rá még 1-et, hanem 2,5-ből vagy még többől csinálok egy olyat, ami az én elvárásaimnak tökéletesen megfelel -- bár tökéletesség nincsen, de ettől most tekintsünk el. És rohadtul nem fog érdekelni, hogy XY milyen fasza vázat csinál, ha az nekem nem jó, átalakítani meg sok értelme nincsen (vagy nem kifizetődő).

Az, hogy ez a szemlélet a ti főnökeiteknek forintálisan (rövidtávon) nem kifizetődő, egy egészen más kérdéskör.

Nézd meg pl. a SpaceShip One és hasonló projekteket. Hatalmas pénzeket ölnek saját fejlesztésekbe és nem a rövidtávú megtérülés a kérdés. Hanem a "képes vagyok megcsinálni" és ha valóban fontos a pénz, akkor hosszú távon kell gondolkodni. Ez viszont ugye teljesen szembe megy a kapitalista társadalom "azonnal sok pénzt keresni a leghatékonyabb módon" című történettel.

Azt pedig én sosem mondtam, hogy jobb keretrendszert csinálok. Azt mondtam, hogy adott szituációban, adott feltételek mellett jobb megoldás egy saját fejlesztés, a körülményekre specializálva, mint egy általános megoldás.
22

Ezzel csak az a baj, hogy nem életszerű

Thoer · 2010. Jan. 5. (K), 20.11
Nem ismerem a SpaceShop One projektet, de a többség itt pont kisebb projektekben gondolkozik. Ahogy azt korábban te is felvetetted:
Az a baj szerintem, hogy akik itt komolyabb tudás birtokában vannak és komolyabb rendszereket fejlesztenek már nem tudnak kicsiben gondolkodni.

Ahol a skálázhatóság már tényleg az elengedhetetlenség netovábbja, ott biztosan nagyon kell figyelni, de tapasztalat nélkül is úgy érzem, hogy ez csak szűkíti a választható keretrendszerek listáját és nem zárja ki azokat. Persze elképzelhető, hogy ilyen esetben tényleg megéri az a temérdek munka a gondos tervezést, fejlesztést, tesztelést és dokumentálást, de szerintem végeredményében ez csak egy új (zárt) keretrendszer használatát eredményezné a lényeges rész fejlesztése közben.

Ha valakinek van ideje, kedve, forrása vagy épp szüksége egy új keretrendszerre, akkor meg kell csinálni, de itt a többség projektek befejezéséből él szerintem, amihez egy jó keretrendszer óriási segítség. Ebből a szempontból teljesen mindegy, hogy a főnököd fog kirúgni ha lassan készül a munka, a csapat nem kap meg projektet ha nem versenyképesek az ajánlatok vagy éppen "csak" te nem vagy olyan hatékony a kis projektedben, mert azzal szöszölsz, hogy hogy kéne megoldani a 12-es hozzászólásomban részletezett problémákat.

Az meg, hogy a keretrendszer saját fejlesztésed vagy nem az már mérlegelés kérdése, de szerintem ezrelékben sem mérhető eset, amikor a saját fejlesztés mindent egybevetve jobb döntés. Ha már a kérdés felmerül egy új projekt esetén, az egyébként már fél siker, de nekem tavaly is csak olyan fejlesztéseket sikerült átvennem, ahol az elődöm annyit nem tett meg, hogy a webkönyvtáron kívül tárolja az adatbáziskapcsolat adatait. Akit interjúztattam az meg csak pislogott a keretrendszer és az MVC szavak hallatán, noha papíron jóval nagyobb tapasztalattal bírt, mint én. Na ez a nagy probléma!
23

Re

Max Logan · 2010. Jan. 5. (K), 20.38
A saját rendszer nem feltétlen csökkenti a produktivitást és nem is igazán kellene összevetni a nagy és sokmindenre felkészített rendszerekkel. Nagy rendszerek általános kérdéseket fednek le. Az én rendszerem, meg mindig más egy kicsit, attól függően, hogy egy munkánál egy kisebb dolgot hogyan akarok megoldani (pl. most eljutott oda a view, hogy már lehet külön layout fájlt, használni. eddig nem volt ilyen lehetőség, mert nem kellett, akkor meg minek legyen a kódban olyan cucc, ami az életben nem fut le -- tudom, ez elég elméleti dolog és idealizálás, de nekem az egyik lényeg az egészben). Ennek következtében nincsen verziószáma és az egyes változatok nem kompatibilisek egymással, mert pont az a cél, hogy ne legyen általános. Az igényeknek megfelelően szabom át pl. az MVC core-t is. Erre (is) mondtam, hogy célspecifikusság.

Ami a 12-es kommentet illeti. Van kidolgozott XSS védelem a rendszerben. És tök jó dolog volt kiszenvedni, hogy ezt hogyan kéne megvalósítani a gyakorlatban, az én rendszeremben.

Ami a form kezelést illeti. Lehet, hogy 1 perc egy form, de pl. nem ott vannak a hibaüzenetek ahol én akarnám, nem úgy kapom meg a hibaüzeneteket a programom belül ahogyan én akarnám (néztem konkrét példát valamelyik form kezelőnél -- forráskód -> eredmény, megnéztem nem tetszet). Ergó írjak saját form modult az adott keretrendszerhez. Azaz van egy valami, amit én bővítek a saját megoldásommal. Akkor miért nem írnám meg az alapot is így ahogyan én akarom.

Tudom, hogy nagy projektekben, gyors eredményorientált szemlélet és a mai "rohanó" világ (ami csak átbaszás, semmi sem rohan, csak ezzel lehet a fogyasztásra ösztönözni) szemlélete szerint ez nem feltétlen jó megoldás. Én másik oldalról fogom meg a kérdést, nem az az elsődleges szempont, ami mondjuk egy 10-20 millás befektetés esetén fontos egy megrendelőnek és a kivitelezőnek. De mint írtam, jelentősen másképpen szemlélem a világot, mint ahogyan az átlag.

Ami pedig a felhozott példát illeti. Proclub elég sokat mondogatta mindig, hogy webroot-on kívülre tenni mindent. Ennek fényében alakítottam ki a mostani rendszeremet. Sőt még az index.php-t is elrejtettem (mod_dir).
24

Biztonság

Thoer · 2010. Jan. 5. (K), 21.15
Saját XSS védelmet én sosem készítettem, mert amikor még nem használtam keretrendszeretek, akkor talán azt se tudtam, hogy mi az. Azt viszont tudom, hogy szinte minden keretrendszerhez sorra jelennek meg a biztonsági frissítések és tökéletes XSS szűrőt se épített még senki elsőre, talán nincs is olyan.

Igaz, hogy egy nyílt forráskódú szoftver esetén hamarabb előjönnek ezek a kérdések, de az is biztos, hogy jobb érzés úgy aludni, hogy tudom, párhavonta frissítve vannak az ügyfeleim rendszerei, mintha abban kéne bíznom, hogy amit pár éve készítettem az ugyanúgy kiállná az idő (és a hackerek) próbáját több év után is, vagy legalább senki nem fogja próbálgatni...

A keretrendszerek standardizáltságának pedig pont az egyik nagy előnye, hogy a frissítések telepítése sok esetben percek kérdése csupán. Ehhez képest te magad is belátod, hogy ez a saját rendszereidben komoly művelet lenne. CodeIgniterben így kell az első komoly bétáról a legfrissebb verzióra bővíteni: http://codeigniter.com/user_guide/installation/upgrading.html. 1.5.4-ről 1.7.2-re 1-2 óra alatt fel lehet készíteni egy átlagos honlapot, pedig a kettő között 2 év telt el!
Nem mondom, ezt a rendszert néha nekem is berhelnem kellett annak idején, de a kiforrottabb frameworkök esetén ez ritkábban fordul elő és idővel az ember ezt is külön vezeti projektenként, ahogy persze a dokumentáltság sem érhet véget a keretrendszernél és használt moduloknál...

Még valami: Azt mondod most már többet tud a rendszered mint eddig. Tök jó, de ez most azt jelenti, hogy ha legközelebb olyan szoftvert fogsz írni, amihez nem kell az új funkció, akkor inkább visszanyúlsz a régihez? Mert ha nem, akkor lassan-lassan ugyanúgy tele lesz a szoftvered ki nem használt funkciókkal, mint az elterjedt keretrendszerek csak ezt más rajtad kívül nem fogja ismerni...
26

Re

Max Logan · 2010. Jan. 5. (K), 21.34
Mint írtam projektenként szabom át a rendszert. A rendszer egyébként kb. néhány kialakított könyvtárból és egy maroknyi osztályból áll. No meg az egyéb külső libek.

Törekszem olyan megoldások alkalmazására, hogy minden rendszerben csak az legyen, ami kell. Pl. írtam régebben egy log cuccost. Amikor izlelgettem az OOP-t, akkor megírtam az alap osztályt, majd abból kiterjesztve a konkrét megoldásokat. Aztán a végén mikor újra átnéztem a cuccot, akkor írtam 1 db függvényt, ami ugyanazt a funkciót látta el. Igaz, hogy nem OOP, de éppen azt a funkciót látja el, ami előtte 3-4 összefüggő programrészből állt.

Tehát nem visszalépek, hanem létrehozok egy egyedi példányt, ami bizonyos részen több és/vagy kevesebb, mint egy előző példány. Nincsen olyan, hogy a keretrendszer, mindig más, nincsen állandó állapota. Kidolgoztam egy alapot arra, amilyen környezetben fel akarom építeni a programom. Az egyes munkáknál meg alakítom. Ez a célspecifikusság a programozás szintjén. A program olyan, amilyennek az aktuális helyzet megkívánja.
28

Én nem alkalmaználak

Thoer · 2010. Jan. 5. (K), 23.13
ugyan programozóként, de mivel te nem is szeretnél alkalmazott lenni, ezért ez egyikünknek sem probléma. Bár fenntartom, hogy valószínűleg mindenki profitálna abból, ha egy összeszedettebb rendszert építenél/használnál, vagy ha megosztanád a műved másokkal, de ez csak az én szerény nyomott véleményem. Ugyanakkor az is igaz, hogy az eddig kiderültek alapján nem miattad szorgalmazom én nagyon a framework használatot, még az is elképzelhető, hogy nem fejelgetném a monitort, ha egy általad hátrahagyott projektet kellene átvennem. ;)
29

Max Logannek

fchris82 · 2010. Jan. 6. (Sze), 12.37
Már nem tudtam, hogy hol is reagáljak, úgyhogy legyen mondjuk itt :)

Én elég jól ismerem a Symfony-t és használom rendszeresen. Ennek ellenére fél éve csináltUNK - merthogy többen dolgozunk együtt - egy sima HTML-es weblapot, 1 hónapja pedig egy Wordpress-eset adtunk át. Az a helyzet, hogy a te fejedben az van, hogy "MINDENKI vélaszt EGY üdvözítő megoldást - módszert - és mindenhol azt használja". Holott a keretrendszer használata NEM MÓDSZER, hanem ESZKÖZ!
Vagy használom, vagy nem. Ez attól függ, hogy mi a feladat, mennyit hajlandó rá szánni a megrendelő, MIKORRA KELL, a munkát át kell adni majd más fejlesztőnek vagy sem, ki a célcsoport, kik fogják használni, stb...

Említetted, hogy nem szereted a CMS-eket. De az előbb említett Wordpress-es munkánál a következő feltételek voltak:
- nagyon gyorsan kellett elkészülni
- ritkán változó tartalom
- a tartalmat a megrendelő szeretné kezelni (képekkel!)
Az egész 5 nap alatt készült el, amiből 3 nap volt a design, 2 nap a szükséges Pluginok megírása és betanítás - nem 8 órás munkanapokról beszélek, mert közben más projekteket is csináltunk. Átadtam egy jól dokumentált, könnyen használható rendszert, kép és médiakezeléssel egyetemben, mindezt 100 000 Ft alatt. Ezzel nehezen fogsz versenyezni, saját PHP programozással, még Symfony-val is.

Az, hogy a keretrendszerek rád kényszerítenek dolgokat, a világ legnagyszerűbb dolga! Ugyanis ott használsz keretrendszert - én legalábbis -, ahol a projekt akkora és előre nem látható a végeredmény, tehát állandóan változni fognak az igények. Rengeteg ilyen munkánk van! Ezek szerint neked még ilyen nem volt. Ez nem baj! Nincs azzal baj, hogy nem használsz keretrendszert, mert ezek szerint neked még nem volt rá szükséged, és nem láttad, hogyan spórol meg neked hónapokat a fejlesztésben. A "baj" az, hogy kicsit szűklátókörűen megkérdőjelezed a létjogosultságát a keretrendszereknek.

Amire ki akarok lyukadni és sztem egyetértésre vezethet: "Mindenhol keretrendszert használni ugyanolyan hibás elképzelés, mint sehol sem használni." És ez vonatkozik a CMS-ekre is. Nagyon ritkán kell, de akkor semmi mással nem érdemes próbálkozni. Lehet jól és személyre szabottan dolgozni keretrendszerrel is, ráadásul ha már letudtad a tanulóidőt, rendkívül gyorsan is A helyzet az, hogy fontosabb, legyen egy program, mint hogy legyen egy igazán jó, végletekig optimalizált program.
30

Célok

Max Logan · 2010. Jan. 6. (Sze), 13.21
Hogy rövidre fogjam. Fentebb említettem, de akkor ezek után, a leírásod alapján meg tudom fogalmazni, hogy mi a helyzet.

A keretrendszerek használatával nincsen gondom. Megértem, hogy miért jó, főleg csapatmunkánál, továbbadható projekteknél. Ez a tipikus "droid" (munkásember, fogaskerék a gépezetben) megközelítés, amikor dolgozol valakinek, mint programozó, vagy éppen olyan környezetben dolgozol, ahol fontos a továbbadhatóság. Ebben az esetben egyértelmű, hogy az optimális megoldás egy általánosan ismert és használat alap rendszer.

Én más szemléletben dolgozom és _olyan_ munkákat keresek és csinálok, amire úgy gondolom, hogy az én szemléletem a megfelelő (és mint a gyarkolat is mutatja, van kereslet az egyedi, személyre szabott, nem általánosított megoldásokkal létrehozott munkára). Tehát az én szemléletemnek megfelelő munkákat keresek, és olyan ötleteken dolgozom, ahol az elgondolásaim jól működnek (és most nem csak a WEB-es programozásra gondolok).

Erre mondtam, hogy nem tudtok más munkakörnyezetet és másfajta igényeket elképzelni, mint amiben ti mozogtok.
31

:)

fchris82 · 2010. Jan. 6. (Sze), 17.58
Erre mondtam, hogy nem tudtok más munkakörnyezetet és másfajta igényeket elképzelni, mint amiben ti mozogtok.

:D

Mi, 2009-ben négy olyan munkát vettünk át, amit hasonló szemléletű ember készített. Abszolút full egyedi volt. Nem volt semmi gond a kóddal, értették a dolgukat a srácok. Csak nagyon feladat orientáltan estek neki, aminek az lett a következménye, hogy lett egy abszolút egyedi, bizonyos feladatokra kiélezett rendszer. Ja, hogy időközben nőtt a cég, és a jogosultság kezelést meg kellene változtatni, vagy hogy teljesen újfajta, a korábbiaktól merőben más termékkel léptek piacra, esetleg új szolgáltatással bővült a rendszerük, a külföldi piacra is kilépnek és többnyelvűnek kéne lennie az oldalnak vagy csak egyszerűen a fejlesztés nyúlt mint a rétestészta - az egyedi fejlesztő nem volt felkészülve a gyorsan változó igényekre és az alapot újra és újra kellett írnia - másfél év alatt sem fejezték azt be, amit mi fél év alatt simán!
Ennek az lett a következménye, hogy egyeztetés után kidobtuk az összeset és elkezdtük azt is leprogramozni, ami már igazából egyszer meg volt írva. Ha engem holnap elüt a villamos, bármelyik programozó át tudja venni a munkámat.

Azt hiszed, hogy mert én mások által, általánosan, széles körben ismert eszközökkel dolgozok főként, az alacsonyabb értékű lesz, pedig éppen ellenkezőleg! Azt nem gondolhatod komolyan, hogy te egyedül kitaláltad a frankót és a programozók többsége téved. Nem véletlen a keretrendszerek népszerűsége és nem véletlenül szajkózza mindenki, hogy:
- használj beszédes változóneveket
- kommentálj
- legyen verziókövetésed
- ismerj meg új nyelveket és eszközöket folyamatosan!
- előbb ismerd meg, hogy mit is akar az ügyfél tényleg
- előbb fejlessz és utána optimalizálj
- ...

Vannak, amiket nem veszek át. Pl a többnyelvűség kezelésére saját rendszerem van, mert mások voltak az igények és a saját jobban megfelelt, mint ami mondjuk a Symfony-ban van. Az igényekhez szabom az eszközöket és a megvalósítást. És mindezt a lehető legrugalmasabban és legáltalánosabban! Mert előfordulhat, hogy pl ki akarok szállni egy fejlesztésből vmi oknál fogva - van ilyen -, vagy csak évek múlva másnak kell fejleszteni a programom, akkor önzőség úgy fejleszteni, hogy "ezt úgyse fogja rajtam kívül senki látni".

Én értem, hogy amolyan művészlélekként egyedit szeretnél alkotni kis mennyiségben, és nem a tömegtermelésre hajtasz, de ezt akkor is lehet, ha használsz kész eszközöket! Csak így nem kell huszadszorra is megírnod ugyanazt, és más problémák megoldására koncentrálhatsz...

Te feltételezed, hogy vízesés módszerrel megoldható a fejlesztés. Az ügyfél az elején tökéletesen tudja, mi kell neki, te leprogramozod és ő átveszi. Ez annyira ritka, hogy én 10 év alatt 2-szer találkoztam ilyennel, de inkább 1-gyel, mert az egyik azóta megkeresett, hogy írjuk át, mert kellene bele ez és ez. Az igények változnak, van, hogy már menet közben 180 fokkal, a keretrendszer jó keretet ad ezek (gyors és problémamentes) lekezelésére. Hiszen ez a dolga. Lehet hozni itt kerékpáros és hasonló példákat, hogy miért jobb az egyedi igényes fejlesztés, de itt programról beszélünk és emberi igényekről. Azok meg változnak. Ma hegyen akarok erdőben, holnap meg országúton akarok gyorsan menni, és mindezt ugyanazzal a bringával! Lehet ragaszkodni az egyedire szabott rendszerhez, csak baromi költséges és lassan reagáló lesz.
32

Re

Max Logan · 2010. Jan. 6. (Sze), 20.49
Futhatunk még köröket, de nem igazán van értelme.

Én látom több helyen, hogy van igény az egyéni megoldásokra. Nem önzőség a hozzáállásom, hanem stratégia. Ami pedig a másnak átadást illeti, ha ez benne van a dologban (ami adott esteben már a kezdetek kezdetén tárgyalási alap lehet), akkor olyan szinten van kialakítva a rendszer (funkcionális specifikáció, stb, stb.), hogy más érdemben át tudja venni és folytatni tudja (és itt jön a képbe az, hogy a köv. ember is olyan szemlélettel dolgozzon a motorház alatt, mint az előd, mert ugye az igény adott volt erre).

Ha már jelentősen változtak az igények, akkor az én szemléletem alapján eljön az a pont, amikor akár az egész eddigi rendszer megy a kukába (max. az elvek, tapasztalatok maradnak), mert ez a kifizetődő és igazán ideális megoldás.

Persze ahol a pénz az úr, ott ez a megközelítés nem működőképes -- na én nem ilyen embereknek és nem ilyen munkákon akarok dolgozni; multik és nagyratörő pénzes projektek (durván profitorientált) nálam alapból kiesnek -- ez elvi kérdés. (Volt már rá példa, hogy kiszálltam egy olyan munka megpályázásából, ami hosszú évekre biztos munkát és folyamatosan pénzt hozott volna -- más az értékrendünk, más munkákat keresünk).

A biciklis példához meg csak annyit, hogy trabival nem indulunk Forma 1-en, még ha tuning akkor sem. Nem hiába van spéci downhill bringa, trial, országúti, stb. Mindegyik bicikli de mégis ég és föld a kölönbség (mindegyik egy specializált, feladatorientált keretrendszer ha úgy tetszik).

Értem az álláspontotokat, van olyan része, amit idővel be is építek a munkamódszereimbe, de ettől függetlenül más utakon járok mint ti. Ennyi az egész. Más értékrend, más problémák, más munkamódszerek.

Egyébként meg ha már előkerült az előre optimalizálás kérdése (amit egyébként magam sem csinálok -- és ezt a szemléletet is a WL-on szedtem fel és építettem be a munkamódszereimbe), akkor az általános rendszer használata is előre optimalizálás (de ebbe már inkább nem mennék bele).

Értem az álláspontotokat, bizonyos tekintetben egyet is értek vele, de más utakon járok.
33

Aha :)

fchris82 · 2010. Jan. 7. (Cs), 00.28
Értem, bár nem "fogadom el". Innentől már a párbeszéd írásos folytatásának semmi értelme, úgyhogy maradjunk ennyiben ;)
34

Záró gondolat -- off

Max Logan · 2010. Jan. 7. (Cs), 01.24
A következő gondolat túlmutat a fenti beszélgetésen és off. Az élet alapvetően úgy működik, hogy erőteljesen dolgozik a vonzás törvénye. Ha te piros gumilabdákat akarsz eladni sárga pöttyökkel, akkor el fogod tudni adni, lesz rá vevő.

Ennek alapján mindketten megtaláljuk a számításunkat az életben, mivel mi teremtjük meg a saját világunkat, bevonzuk azt amit akarunk és amit nem (mert nem az számít, hogy akarjuk vagy sem, a gondolatainkkal megteremtjük saját világunkat -- véletlenek nincsenek, a szerencse még kevésbé, a "sorsunk előre megvan írva" gondolat pedig pusztán hárítás, hogy a világ(unk) alakulása nem rajtunk áll; pedig de).
35

XSS

tgr · 2010. Jan. 7. (Cs), 10.43
Ami a 12-es kommentet illeti. Van kidolgozott XSS védelem a rendszerben. És tök jó dolog volt kiszenvedni, hogy ezt hogyan kéne megvalósítani a gyakorlatban, az én rendszeremben.


Majd nézd meg, hogy az XSS cheatsheet támadásainak mekkora részét fogja meg. Ízenlítőnek itt van egy:
<DIV STYLE="background-image:\0075\0072\006C\0028'\006a\0061\0076\0061\0073\0063\0072\0069\0070\0074\003a\0061\006c\0065\0072\0074\0028.1027\0058.1053\0053\0027\0029'\0029">
Saját keretrendszer használatának lehet értelme (bár ez nem ugyanaz, mint az eredeti cikkben szereplő no-framework, aminek szvsz nincsen), saját XSS szűrőének legfeljebb akkor, ha XSS-re specializálódó biztonsági szakértő vagy.
39

Írtam egy hosszabb véleményt

Thoer · 2010. Jan. 9. (Szo), 12.53
a témával és az itt beszéltekkel kapcsolatban.