Ha webfejlesztésről van szó PHP-ban, akkor mire szeretsz építkezni?

PHP

Nulláról írt PHP kódra
14% (71 szavazat)
Egy web framework-re (Zend, Symfony, Yii stb.)
15% (73 szavazat)
Egy CMS-re (Drupal, Joomla stb.)
15% (74 szavazat)
Saját építésű framework-re / CMS-re (amit nulláról írtam / írtunk évek alatt)
10% (49 szavazat)
Saját építésű framework-re / CMS-re (felhasználva / módosítva más framework / CMS kódját)
1% (6 szavazat)
Sosem PHP-t használok webfejlesztéshez
18% (89 szavazat)
Egyéb, leírom hozzászólásban
2% (12 szavazat)
Nem értek a webprogramozáshoz
24% (118 szavazat)
Összes szavazat: 492

( Cseresznye | 2013. 09. 20., p – 09:58 )

"Sosem PHP-t használok webfejlesztéshez"

Elég sok a majd 40%, akár egy új szavazás lehetne, hogy ez a csoport mit használ.

Attol fugg mire vagy kivancsi. Mindketto erdekes lehet. A te kerdesed valojaban az lenne, hogy "Mi a kedvenc webes nyelved?" De ha nem tesszuk hozza ezt a kikotest (hogy "ha semmilyen megkotes nemlenne akkor mit hasznalnal"), akkor arra kapunk valaszt, hogy tenylegesen mit hasznalnak az emberek (midndegy, hogy mindek hatasara). Szerintem ez az utobbi amugy hasznosabb.

Én se értem, mi értelme van a Perl-nek, amikor ott a jó öreg C...

Néhány hete vagy talán hónapja rábukkantam a "vidir" nevű programra. Nagyon megörültem neki. Nézegetem, hű, ez tök rövid, oké, csekkoljuk csak meg a forrást hogyan csinálja a fejlesztője, hátha tanulok belőle valamit... Erre nagy döbb és zizz: Pffffff... Ez biza nem C-ben van, nem is C++-ban hanem PERL-ben! Pedig én hogy úgy mondjam "el akartam lopni", beépíteni az egészet egy készülő programomba...

Igazából ezen annyira megmérgelődtem, hogy nem adtam fel, s elkezdtem meredten nézni a kódot. Mondok magamba' : állítólag egyes varázslók képesek rá hogy addig nézik a sziklát mígnem forrás bugyog elő belőle... hátha hogyha eleget bámulom a forrást, abból meg tudás fakad az elmémbe!

(Nem, nem kezdtem el Perl kézikönyvet olvasni. Tudom, RTFM. De én nem akartam megtanulni Perl-ül. Csak azt az egy programot akartam...)

S lőn tényleg csoda, az elszántság és akarat diadala: már egész jól értem, mit csinál, hogyan és miért! És NEM, tényleg nem értem, ezt miért nem lehetett megírni C-ben! Ha lesz egy kis időm a napokban, igenis megírom benne, még néhány plusz feature-ot is belesúvasztok talán...

Pláne mert amennyire tudom, a vidirt senki nem "tartja karban" már.
-------------
Honlapom: http://parancssor.info
Könyvem a VIM-ről: http://mek.oszk.hu/09600/09648/#
=== Sabayon disztró, DWM ablakkezelő ===

Nekem nincs ilyen fetisem, hogy valami csak x nyelvben lehet, a legtobb elterjedt nyelv tavolrol elegge ugyanolyan. C/C++, Java, C#, PHP, Bash, akarmi. De amikor ranezek a Perl kodra, elfog a hanyinger. A my, a {}{}{}{}{}, a regex, komolyan, REGEX?! Nem sok olyan (szamomra) undorito dolog van a programozasban, mint a regexek, erre a Perl tele van vele. Aki irta, az mondjuk erti legalabb 2 napig, utana meg egy szenvedes kibogoznia. Barki masnak meg agyhalal. Oke, hogy nagyon hatekonyan lehet kifejezni dolgokat, de olvashatosag, debugolas, karbantarthatosag, ujrafelhasznalhatosag szempontjabol a zerohoz konvergal. Nekem kb. olyan, mintha brainfuck kodot olvasnek. Innentol eselytelen, hogy en es a Perl valaha baratok legyunk.

O, ezt anno egy okos kollega sokkal-sokkal okosabban megoldotta. Bar szoltunk neki, hogy melyik az az osztály, ahol kb. Az adoszam validalasig (nem csak formára, checksumra is), erre irt sajatot: annyit ellenőrzött benne, hogy van benne pont meg kukac.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

2 igazi gyongyszem:

- "a legtobb elterjedt nyelv tavolrol elegge ugyanolyan. C/C++, Java, C#, PHP, Bash, akarmi"
- "a regex, komolyan, REGEX?!"

Ez utobbi ugy hangzik, mint amikor Palik a mikrofonba sikitozik egy demonhill eltuneskor...

--
"Pontosan ez a ti bajotok. Ez a kurva nagy csőlátás. [...]" (bviktor)

Vagyis azert szar nyelv a Perl, mert lehet szarul hasznalni? Ez gyakorlatilag minden programnyelvrol elmondhato. A Perlben - ahogy egyetlen mas nyelvben sem - nem kotelezo regularis kifejezeseket hasznalni. Az, hogy nehanyan forditva ulnek a lovon, es az eszkozhoz valasztanak celt, az meg nem jelenti azt, hogy az eszkoz a rossz. Inkabb a megkozelitessel vannak problemak.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Felreerted a dolgokat. Meg lehetett volna irni C-ben, csak nem volt ERTELME megirni C-ben. Ugyanis a C programot le kell forditani a futtatashoz, a Perl-t meg nem kell. Valoszinuleg a vidir szerzoje azt akarta, hogy a programja tobb platformon is megfeleloen fusson. Ez lehet, hogy szamodra, mint felhasznalo szamara nem pozitivum, viszont a fejleszto szamara az, mert nem kell kulon binarisokat keszitenie Windows, OS X, Linux, BSD ala, hanem kirakja a kis perl scriptjet, es mindenki boldogan tudja hasznalni, anelkul, hogy tisztaban kellene lennie a 'compiler' szo fogalmaval.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Már bocs de miért lett volna sokkal bonyolultabb megoldani C-ben?!

Javíts ki kérlek ha hülyeséget beszélek alább:

—Szerintem ez azt csinálja, hogy beolvassa a tartalomjegyzéket, és ezt kiírja egy ideiglenes állományba, minden tartalomjegyzék-bejegyzés elé kreálva egy sorszámot. Aztán erre meghívja a rendszerhez beállított editort, s amikor az béfejezte az ő munkáját, akkor összehasonlítgatja a kapott állományt azzal amit ő megjegyzett magának. E két állomány egy-egy sorát akkor tekinti azonosnak, ha a sorszám azonos. Ha a név is azonos, nem csinál semmit; ha a nevek különbözőek, akkor átnevezi a fájlt/könyvtárat az új névre; ha teljesen hiányzik is a megfelelő számú sor, akkor kitörli.

Na most ez egy faék-egyszerűségű dolog - itt maga az ÖTLET az ami zseniális, le a kalappal előtte! De programozástechnikailag ez olyan "bonyolult", hogy én nyíltan bevallom hogy csak hobbi-programozó vagyok, igazán távol a tökélytől, de ennek ellenére összeszarnám magamat szégyenemben, ha nem tudnám leprogramozni nagyon hamar akkor is ha előbb bevedeltem minimum 6 üveg sört, holott nem is bírom az alkoholt. Igazából azért nem csináltam csak meg még, mert előbb mást csinálok javában, meg van pár ötletem hogy mivel bővítsem ki, de előbb azokat végig akarom alaposan gondolni.

Ha ezt a dolgot valaki tényleg nagyon "olcsón" akarja megoldani C-ben, akkor egyszerűen a system paranccsal hívja meg a megfelelően felparaméterezett ls rutint, egy fájlba irányítva, majd azt beolvassa magának, a sorokat kibővíti a sorszámmal oszt' csókolom. (Oké, mondjuk 2-szer hívja meg az ls-t, egyszer a tartalomjegyzékekre, egyszer meg a fájlokra). Ez kétségkívül rém primitív és durva dolog, de ha csak az egyszerűség fontos... És végülis nem nagy probléma, mert úgyis kell ideiglenes állományba írkálnia a $EDITOR meghívása előtt.

Előkelően megoldva persze bonyolultabb, mert kellenek a mindenféle tartalomjegyzék-listázgató függvények a megfelelő librarykból. De az se olyan rémes, csináltam már én is olyat.

Nem, szerintem semmivel se bonyolultabb ezt megírni mint PERL-ben, kivéve persze ha az aki írja csak a PERL-hez ért, a C-ről lövése sincs.

Továbbá: hogy több platformon is működjön a program?! Ugyan kérem... Nem azt mondtam hogy Assemblerben írja meg. A C forráskód igazán jól hordozható. Úgy tudom direkt olyanra és azért találták ki...
-------------
Honlapom: http://parancssor.info
Könyvem a VIM-ről: http://mek.oszk.hu/09600/09648/#
=== Sabayon disztró, DWM ablakkezelő ===

poli... írd meg C-ben (még a 6 sört se kérem rajtad számon), aztán írunk egy-egy edge case-t, amire nem gondoltál és ami miatt jó esetben csak segfaultol a programod. Aztán küldj javított verziót. Aztán abban találunk edge case-t, azt megint javíthatod.

Hányadik ilyen iterációnál fogadod el, hogy van értelme a C fölé menni?

BlackY

Abban egyszerűbb, ami arra való és még értesz is hozzá.
A szar szoftverek többségének pont az a baja, hogy nem a megfelelő eszközt használják a megfelelő célra, vagy a developer (team) nem ért hozzá - a hozzáértés hiánya lehet magához a programnyelvhez viszonyított is, meg ahhoz is, amit le kell kódolni.
De azon fölösleges vitázni, hogy melyikre van nagyobb szükség, mert mindre egyaránt szükség van, méghozzá pont azon a szinten, ahogyan azt az elvégzendő feladat megkívánja.
--
PtY - www.onlinedemo.hu

Szerintem onnantól kezdve, hogy a fájllistát egy system("ls")-el akarja megoldani, megállapíthatjuk, hogy nem ért hozzá.

És egy ilyen tényleg faék util-nál szerintem sokan nem akarnak szórakozni a memóriafoglalással [és teleszemetelni minden malloc után egy iffel, hogy akkor ki is lépjünk], a beolvasáskori buffereléssel (melyik fájlrendszernél mekkora a legnagyobb fájlnév méret, mert ugye ezek maximumának kell lefoglalni a memóriát, ha natív C string műveletekkel játszol) stb. Lehet C-ben robosztus programot írni, csak minek?

BlackY

Az ilyen system() hívásokkal lehet egy szoftver kitűnően uniplatformossá tenni. Aztán, ha portolni kéne, b@sz van.
Régebben ilyen kiváló programokat csináltak DOS alatt, és amikor windows alatt kellett volna futtatni, jöttek a kékhalálok, mert pl. az ember direktben nyúlkált a fájlrendszerhez ahelyett, hogy az int21-et használta volna, ami win alatt kompatibilitást teremtett, míg a direkt használatkor jött a végzetes kivétel :D
Tudom, nem lehet konkrét párhuzamot vonni, de a módszer ugyanazt a hordozhatatlanságot eredményezi.
--
PtY - www.onlinedemo.hu

system("pause")? :)

Az MS-nél valahol van egy írás arról, hogy mi mindent dobtak ki a Windows 7-ből (Vistából?), hogy a korábbi verziók milyen csúnya hackeket tartalmaztak kernel szinten (pl. rémlik olyasmi, hogy process név alapján elterjedtebb DOS-os progik memóriájában turkált, hogy a fentihez hasonló hibák ne jöjjenek elő és Win alatt is fussanak)

pl.: ez: http://www.joelonsoftware.com/articles/APIWar.html [Simcity-re keresve kijön a megfelelő bekezdés]

BlackY

Persze, ma már az MS is tudja, hogy anno pont a DOS "mindent lehet" megoldásai miatt tartunk ott, ahol.
Ezért voltak anno vírusok - amelyek a szó igazi értelmében manapság már alig vannak, de ennek köszönhető az is, hogy az "ártó kód" mit fogalom, közismert lett, és fegyverré vált.
Vajon milyen lenne ma a világ, ha anno nincs PC DOS?
--
PtY - www.onlinedemo.hu

Te magad adtad meg a választ.
Ha csak system hívásokat csinálsz, akkor gyakorlatilag egy bash scriptet írtál, mert semmivel sem lesz jobb annál. Ergo max a nyálad tudod verni rá, hogy C-ben van, de a végeredmény kb. egy parasztvakítás lesz csak (amit ugye Te nagyon nem szeretsz).

"Előkelően megoldva persze bonyolultabb, mert kellenek a mindenféle tartalomjegyzék-listázgató függvények a megfelelő librarykból."

Erről beszélek. Állj neki és meg fogod látni, hogy a C-ben írt végeredmény jóval összetettebb munka lesz, mint a Perl megoldás.

Vannak esetek, amikor igenis nem érdemes megoldani C-ben az adott problémát, mert nem fog a többlet munka semmilyen pluszt hozzáadni a működéshez. Ez nem egy teljesítményorientált feladat, aminél minden bit számít.

Alapveto problema, hogy mar a tartalomjegyzek beolvasasa is viszonylag bonyolult C-ben, mar amennyiben nem a system("ls") paranccsal akarsz operalni, hanem TENYLEG multiplatformra szeretned megirni.

Azutan, az osszehasonlitas - foleg azert, mert a C-ben egyaltalan nincsenek sem sztringek, sem hashek - megintcsak nem tul rovid folyamat. Nem azt mondom, hogy megoldhatatlan, hanem azt, hogy nem tul rovid.

Gondolj bele, az ls parancsot le lehet programozni bash-ben, hogy pontosan ugyanazt a kimenetet, pontosan ugyanazokkal az infokkal adja ki a script, mint amit a standard ls - csakhogy nincs ertelme, hiszen ezt mar egyszer megirtak, ott az ls parancs, kiadom, es vigan lehet hasznalni. Nagyjabol en emiatt ertem meg a Perl hasznaltot is (ja, es a Perl - bar betuszo - helyesirasa nem a vegig nagybetus verzio), hiszen senki nem akar feleslegesen olyan dolgokat implementalni, amit valaki mas mar megtett.

Arrol nem is beszelve, hogy te mindig elsiklasz a multiplatformitas kerdese felett. Egy C program soha nem lesz annyira multiplatform, mint amennyire egy Perl script lehet.
Ha forrasban terjeszted: a felhasznalo oldalan telepiteskor rendelkezesre kell allnia egy C fordito kornyezetnek. Ez a te meg az en gepemen megvan, de mas gepeken nincs; nem beszelve a C forditas relative nagy eroforrasigenyerol, akar egyetlen C fajl eseteben is.
Ha binarisban terjeszted: folyamatosan figyelned kell az API/ABI valtozasokra. Ugyanaz a szoftver nem fut el Linuxon es BSD-n, raadasul idonkent egyszeruen mindent ujra kell forditani, mert megvaltozik az ABI kornyezet. Mar maganak ennek a problemanak a menedzsmentje elvisz annyi idot, ami konkretan megindokolja a Perl hasznalatat.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Ha forrasban terjeszted: a felhasznalo oldalan telepiteskor rendelkezesre kell allnia egy C fordito kornyezetnek. Ez a te meg az en gepemen megvan, de mas gepeken nincs; nem beszelve a C forditas relative nagy eroforrasigenyerol, akar egyetlen C fajl eseteben is.
Ha binarisban terjeszted: folyamatosan figyelned kell az API/ABI valtozasokra. Ugyanaz a szoftver nem fut el Linuxon es BSD-n, raadasul idonkent egyszeruen mindent ujra kell forditani, mert megvaltozik az ABI kornyezet. Mar maganak ennek a problemanak a menedzsmentje elvisz annyi idot, ami konkretan megindokolja a Perl hasznalatat.

Erre vannak az adott disztribúció csomagolói. Ha meg a felhasználó megtalál egy "fusi-programot" és használni akarja, akkor legyen képes egy INSTALL fájl alapján telepíteni. Ha a program, amit telepíteni akar, parancssoros, elég valószínű, hogy nem először fog életében parancssort látni.

Khmm... windows... khmmm...

De nem is errol van szo. Nem minden csomag kerul be a disztribuciokba, es amig nem kerul be, addig sajnos neked, mint fejlesztonek kell gondoskodni a terjesztesrol, ami visszavezet minket a 'forditsuk-e le ugyanazt a programot otszor avagy irjuk meg Perlben es egy darab scriptfajlt kell terjeszteni' kerdeshez.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Először is: Robitusin a köhögésedre :)
Értem én, mire gondolsz, de minden egyes apró-cseprő programot felesleges (és szerintem nem is kell) berakni a csomagválasztékba. De ha valaki megtalálja ezt a parancssoros progit és azt akarja használni, annak le is kellene tudnia fordítani.
Persze, egy szkript sokkal egyszerűbb ebből a szempontból, ezt egy percig se vitattam.

Koszi, mar gyogyulok :-)

En sem mondom azt, hogy minden szirszar keruljon be a csomagvalasztekba, nem az Arch Linux meg az AUR az alap szamomra se.

De en meg emlekszem, amikor kezdtem ismerkedni ezzel az egesz Linuxozassal, es megprobaltam magmnak forditani egy kis tool-t, ami valamihez kellett (asszem a regi Genius kezi scannerem meghajtoja volt), es tudom, hogy mennyi szopas volt vele. A C forditasra sok rosszat lehet mondani, de hogy konnyu lenne debugolni...

Raadasul Windowsra meg annyira se egyszeru a dolog. 5 evnyi Gentoozassal a hatam mogott, meg mindig meg tudnak szivatni Windowsos forditas soran bugok.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Bocs de 2 dologban hadd kötekedjem.

1. Ha elvben és általában igazad van is, de aki a tartalomjegyzékét kézzel, vidirrel akarja manipulálni, az feltehetőleg nem annyira kezdő hogy ne tudna forrásból telepíteni, így lesz C compilere is.

2. Oké, kell egy C compiler. De a Perl szkripthez meg egy Perl interpreter. Megkockáztatom, ez kevésbé általános része egy disztrónak mint a C compiler, ritkábban van fenn. De ha ugyanolyan gyakran, nos, akkor is ugyanott vagyunk, semmit nem nyert vele. Ha Bash shellben lenne megírva a vidir, azt mondom értem, valóban kevesebb cucc kell a futtatásához. De így?
-------------
Honlapom: http://parancssor.info
Könyvem a VIM-ről: http://mek.oszk.hu/09600/09648/#
=== Sabayon disztró, DWM ablakkezelő ===

1) nem biztos. Tegyuk fel, hogy en olyan PHP fejleszto vagyok, aki VIM-mel fejleszt, hasznalnam a vidir-t, de gozom sincs arrol, hogy mi az a C nyelv. Elkepzelheto? Igen az, mert sem a VIM sem a vidir sem a PHP hasznalatahoz nincs szuksegem arra, hogy tudjam mi az a C nyelv, es hogy milyen compilere van neki.

2) Tevedsz, a Perl interpreter minden Linux disztribucionak szerves resze. Megkockaztatom: nincs olyan non-embedded disztribucio, amely ne tartalmazna a Perl interpreter valamely verziojat. Ugyanakkor alapertelmezes szerint a C compiler sehova nem telepul, a forras alapu disztrokat (Gentoo, Sabayon, *BSD) kiveve.

Arrol nem is beszelve, hogy a sokat utalt Windowsra a C compiler mellett egy csomo egyeb bizbaz is szukseges ahhoz, hogy egy C program (akar egy hello world is!) leforduljon, ugyanakkor Perl interpreterbol mar van egesz baratsagos meretu is.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Nos, ne haragudj de nem értem, miért jössz mindig azzal, hogy Windows alatt mi van. Igazán ismerhetnél annyira már, hogy tudd rólam: konkrétan nagy ívben leszarom a Windows-érát, magasan hidegen hagy, ott mi hogy van/megy, s mennyire nehéz vagy könnyű a fejlesztés. Nehogy már ilyesmi miatt szívassam magam akárcsak annyira is hogy ezen töröm a fejemet, amikor 10+ éve nem használok windowst! Azaz ez nekem nem érv. Még az se nagyon hogy a BSD rendszerekre lehet-e portolni (s hogyan) valamit, de azt mondjuk érintőlegesen, úgy félvállról esetleg hajlandó vagyok érvnek venni, a "futottak még" kategóriában. Na de a Windowst?! Én?! Már bocs... ezt komolyan úgy vélted, mint érv nálam meghallgattatásra kerül?!

A második érved pedig szimplán nem igaz. Eddig 1 azaz EGY disztróval futottam csak össze, amiben alapból nem volt benne a C compiler: az a disztró neve, hogy Puppy. Ahhoz is fel lehetett tenni utólag csomagból, de alapból tényleg nincs benne. Na most ez elég extrém eset/disztró, ugye... Az érved annyira nem igaz, hogy legelső disztróm az UHU volt, ami véletlenül se forrásalapú, oszt' még abban is benne volt a C compiler. De mondok ismertebb példát is: Az az Ubuntu amit soká használtam, a 11.10-es volt. Abban is benne volt nekem a C. Az mióta forrásalapú?!

Amit a VIM-mel PHP-t fejlesztő dologról írtál, igen, elképzelhető. De tudod amit el lehet képzelni, nem biztos hogy létezik is. Mekkora e dolgok együttes esélye? Szerintem kb akkora, mint hogy ha holnap bemegyek a főnök irodájába, az asztalán egy krokodilt találok, a számítógépe tetején pedig egy Yang korabeli porcelán tányért, értéke >1 millió $, s e tányérban egy kupac kaki van.

Minden felsorolt dolog e példámban létezik a világban. Együttes előfordulásuk esélye mégis lim -> 0. Szerintem. S ezt gondolom a te példádról is. Amiatt, mert szerintem a VIM kellően agyérgörcs-okozó nehézségű ahhoz, hogy aki mégis rászánja az időt a megtanulására, annak legyen fogalma a C-ről is azért. Annyira legalábbis, hogy egy ebben megírt programot telepíteni tudjon. Hiszen rém nehéz: make clean install vagy valami hasonló. (nem hiszem ugyanis, hogy e program akár egy külön ./configure létét is kiérdemelné a bonyolultsága miatt).

-------------
Honlapom: http://parancssor.info
Könyvem a VIM-ről: http://mek.oszk.hu/09600/09648/#
=== Sabayon disztró, DWM ablakkezelő ===

Csak mert túl sok szabadidőm van, íme egy Debian minimal install csomaglistája: http://pastebin.com/Qu6xMAPU

Nézzük, mit látunk? Van egy perl-base-ünk, bár ehhez hozzá tartozik, hogy az open.pm hiányára hivatkozva a vidir így nem fut le. Van egy gcc-4.7-base-ünk, amiben csak maga a fordító és a C specifikus cuccok nincsenek benne. 1:1. De menjünk tovább!

Telepítsük a perl-modules csomagot! És működik a vidir. Nézzük C fronton mi lenne a helyzet. Dobjuk fel a gcc-t és gondolatban próbáljuk ki a make && make install utasítást: command not found. Akkor telepítsük a make-t is. Így már, ha nincs semmilyen lib-re függősége, elvileg le kéne fordulnia.

Összegzés:
* Mindkettőből van fenn egy -base, ami a gcc-nél semmire nem jó, perl-nél legalább elindul, de a modulok nélkül nem sok haszna van
* GCC-nél telepíteni kell (minimum, ha tényleg csak a vidir-ről van szó és nincs semmi lib a képben) gcc, make
* Perl-nél telepíteni kell: perl-modules.

Perl:C 2:1.5

Amúgy azt hiszem Uborka se rakja fel még a desktop installkor sem a gcc-t, csak akkor, amikor valami zárt drivert telepítesz, ahol kernel modult kell forgatni, mert ahhoz ugye kell, de nem mondom biztosra. Azt majd megnézi valaki más :)

BlackY

Szinte egyik rendszer sem teszi fel default. Ubuntun/Debianon a build-essential csomag kell, ha nem akarja az ember darabonként pakolászni. Fedora, Centos szintén nem teszi fel alapból, tárolóból kell feltenni.
Ennek alapvetően az az oka, hogy úgy általában véve produktív szerverre fejlesztői csomagokat nem pakolunk fel, azaz tiszta telepítésre egyszerűbb installt nyomni, mint egy éles gépen takarítani a sok vackot.

Ez ok (közben megnéztem egy grep -e "standard\|important\|required" override.wheezy.main -vel, hogy a standard system utilities-ban mi van benne, úgy sincs több gcc, perl-modules viszont van :) ), de kérdés, hogy mit számítunk alaptelepítésnek: ha az alaptelepítésnek vesszük azt is, hogy az első indítás után szól az Ubuntu, hogy "itt van driver, szedjed le" és azzal felteszi a build-essentials-t is, akkor benne van (hasonlóan, a minimal install része VirtualBox alatt néhány xorg-* csomag, mert afaik csak expert installkor kérdez rá, hogy egyáltalán fel akarod-e tenni a guest x drivert, ami függőségként behúzza őket).

Az eredmény mondjuk továbbra is ugyanaz: [használható] Perl nagyobb valószínűséggel van mindenhol, mint [használható] c fordító (hogy ne legyünk gcc-specifikusak).

BlackY

Alaptelepitesnek azt vesszuk, ami alapbol felmegy. A drivercsomag nem megy fel alapbol, csak bizonyos feltetelek egyuttallasakor (ilyen hardvert erzekeltunk ES a felhasznalo kifejezte egyeterteset a drivercsomag telepitesevel kapcsolatban).

Ami a xorg csomagokat illeti, azt tekinthetjuk a virtualbox fuggesenek is, es amennyire tudom, a virtualbox driverek telepitesehez ugyanugy kell nemi interakcio.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

laptelepitesnek azt vesszuk, ami alapbol felmegy.

Na, kipróbáltam. Debian Wheezy, nem expert installal (expert csomgalistáját lásd fenn), de tasksel-nél ugyanúgy semmi nincs kijelölve: http://pastebin.com/X0LSevvZ

Kérdés nélkül felteszi a virtualbox-guest-* csomagokat, és azok függőségeként a korábban említett xserver-* csomagok mellett bejött a C fordító is.

Ezért kérdezem, hogy mit telepítünk alaptelepítésnek. Merthogy mindkettő az, csak az expert-nél explicite letiltottam az X drivert, mert úgy sem kerül rá X11.

BlackY

Kiprobaltad ugyanezt egy vmware gepen is?

Egyebkent oszinten szolva nekem a wheezy kisse feher folt, mert en tobbsegeben meg mindig squeeze rendszereket uzemeltetek, a wheezy egyszeruen tul uj meg. Raadasul asszem mar 5.4-es PHP van benne, arra meg meg szinte semmink nincs felkeszitve.

Amennyire en tudom amugy, korabban a virtualbox-guest csomagoknal a modulok eleve binaris formaban voltak szallitva az alapertelmezett debian kernelhez, igy a gcc fordito nem volt fuggoseg.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

VMWare-nél alapból valóban nem tesz fel xorg drivert, a korábbi expert installos csomaglistához képest viszont ez is változtat (kérdezés nélkül, tippre expert installal rákérdezne) két esetben: felteszi a daemon és az mpt-status csomagot. [VMWare Player 5.0.2, ugyanazzal a debian-i386-7.1.0 netinstall telepítővel, mint a VBox-os tesztek].

BlackY

Akkor egyik emlitett csomag sem resze az alaptelepitesnek, hanem valami kulso indoknal fogva rakerdez. Oke, az user interakcio tulsagosan leszukitette ezt a kort, eddig csak olyan telepitokkel talalkoztam, amiknel ha volt hardverdetektalas, akkor rakerdeztek, hogy mit szeretnek.

Alaptelepitesnek akkor vegyuk azon csomagok metszetet, amely minden gepre felkerul, fuggetlenul annak tipusatol, es fuggetlenul a felhasznalok plusz igenyeitol.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Szerintem értem, mire gondolsz (a bare minimum, amit bootolhatónak ítél egy disztrib készítője, a teljesen minimális install a HW-független elemek nélkül), csak pl. pont itt még az Expert installnál is külön ki kell kapcsolni a Desktop-ot, a Standard System Utilities-t és még valami harmadik task-ot, ami plusz igénynek is minősülhet. :)

BlackY

"Eddig 1 azaz EGY disztróval futottam csak össze, amiben alapból nem volt benne a C compiler"

Bullshit. Csak es kizarolag a forras alapu disztrok TELEPITIK automatikusan a C compilert. Se a Debian, se az Ubuntu, se semelyik kereskedelmi disztro nem telepiti automatikusan. Az, hogy te a GoboLinuxon meg az ArchLinuxon (hint: mindketto forras alapu disztro) nem igazan hasznaltal meg mas disztrot, az nem mentseg.

Az pedig nem erdekel senkit sem, hogy TE hogyan velekedsz a Windowsrol. Arrol van szo, hogy egy szoftver terjesztesenel mire kell figyelni. Es egy szoftver terjesztesenel - foleg, ha olyan altalanosan hasznos dologrol van szo, mint a vidir - igenis szempont lehet a fos Windowsra valo terjesztes.

"De tudod amit el lehet képzelni, nem biztos hogy létezik is. Mekkora e dolgok együttes esélye?"

A tobbit nem idezem be. Megintcsak azt mondom, hogy tulsagosan is kevesse vagy tapasztalt ezekben a dolgokban ahhoz, hogy relevans velemenyt tudj nyilvanitani. En ugyanis tobb ilyen embert is ismerek, es az ismeroseim ismerosi koreben meg tobbet. Valojaban eleg sok emberrol tudok ahhoz, hogy az altalad irt eshetosegnel ket nagysagrenddel gyakoribb legyen az emlitett dolgok eselye.

" legelső disztróm az UHU volt, ami véletlenül se forrásalapú, oszt' még abban is benne volt a C compiler. "

Figyelj, ne akarj hulyenek nezni. Nekem is volt UHU-m, es NEM volt rajta alapbol telepitve a C compiler, utolag felrakhato csomag volt.

"a VIM kellően agyérgörcs-okozó nehézségű ahhoz, hogy aki mégis rászánja az időt a megtanulására, annak legyen fogalma a C-ről is azért"

Nem. A kettonek annyi koze van egymashoz, mint a ketlyuku ferfinak a kilenclyuku hidhoz. Semmi.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Nézd, az első UHU-mat akkor tettem fel, amikor még nem volt semmi internetem. A haverom írta ki nekem CD-re a cégénél. Emlékszem, 2 CD volt. Lehet, hogy a C nem volt rajta az első CD-n. De nekem az volt az első dolgom hogy feltelepítettem a második CD tartalmát is. Kezdő voltam a Linuxban, első disztróm, tudtam is hogy hülye vagyok még benne mindenhez, gondoltam fogalmam sincs melyik program mire való, felteszek mindent, aztán majd megtanulgatom.

És volt C compilerem. És szerintem ha egy disztrót 2 CD-vel adnak eleve, akkor az alaptelepítésnek számít. Ezzel az erővel mondhatnád hogy ha egy disztró csak DVD-re fér rá mert akkora, azon sincs "alapból" a C, hiába hogy ott van, mert ugye nem muszáj felrakni mindent ami rajta van a DVD-n.

És igenis én az Ubuntuban a 11.10-et használtam és minő csoda, volt C compilerem. Nem tudom miért tette fel magának, tény hogy én külön nem mondtam neki hogy tegye fel. Nem is láttam amikor telepítette. Eszembe se jutott különben arra gyanakodni hogy hátha nincs, nekem természetes volt hogy egy Linux disztróban ez alapból illik hogy benne legyen. Egész mostanáig e topikig ezt hittem, bevallom. Igaz, tapasztaltam hogy a Puppyban ez nincs így, de azt extrém esetnek, kivételnek tekintettem.

És használtam Slackwaret és Zenwalkot is egy darabig. Azokban is volt C. Pedig azt hiszem azok se forrásalapúak.
-------------
Honlapom: http://parancssor.info
Könyvem a VIM-ről: http://mek.oszk.hu/09600/09648/#
=== Sabayon disztró, DWM ablakkezelő ===

A megoldást lásd a néhánnyal fentebbi hozzászólásomban (még a Debian telepítő is kérdés nélkül felrakja a C fordítót, ha megfelelő dkms csomag szóba kerül) ill. a sajátodban (mindent fel kell tenni... ami amúgy szerintem többé-kevésbé lehetetlen, mert azért "elő-elő fordulnak" [értsd: garantáltan vannak] conflictoló csomagok)

BlackY

Akkor most nekem is fe kellene trlepiteni a debian minimalra a szukseges cdomagokon kivul mind a 30k-nyi csomahot, však mert vám olyan cd es,dvd terjesztes, amiben benne volt? Bullshit.

slackware meg mindig is a vallogasd es konfigold be magadnak sisztro volt, ertelmezhetetlen až a fogalom, hogy slackware alaptelepites.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nem határeset (kivéve, ha ilyen értelemben :) ). A bináris csomagban levő cuccok száma elég nagy, akinek nincsenek nagyon speciális igényei, nem is igen találkozik az aur-ral. Te hány csomagot használsz AUR-ból?

Attól, hogy van egy (vagyis több) olyan nem-hivatalos (ill. nem-támogatott) eszköz (ld. itt: Yaourt is an unofficial, third-party script that is not supported by the Arch Linux developers.), amellyel egy olyan gyűjteményből, ahova bárki feltölthet bármit, lefordíthatsz bármit, még nem forrás-alapú. A hivatalos csomagkezelővel, a pacman-nal csak bináris csomagot tudsz telepíteni. A rendszer elemeinek újrafordításának támogatása (de szépen mondtam :) ) meg elég sok bináris disztróban megoldható (különben hogyan készülnének bináris csomagok?). Sőt, Arch alatt nem is igen tudsz egykönnyen "személyre szabottan" fordítani egy már elkészült PKGBUILD-et, csak annyiban, hogy saját gcc-paramétereket adhatsz meg - ha meg valami opciót/feature-t nem akarsz belefordítani, vagy a hivatalos verzióval ellentétben igen, akkor vagy belenyúlsz kézzel a PKGBUILD-be, vagy valami kerülő utat jársz (pl. customizepkg és yaourt), mint pl. én.

Egyébként milyen idiótaságokra gondoltál?

Nem tudom, nekem telepites utan hirtelen jopar csomag kellett az AUR-bol, pl. Sun/Oracle (nem tudom, amikor neztem, megvolt-e a valtas) Java es a VMware modulok ami most igy hirtelen eszembe jut, de tudom, hogy volt sok (egyebkent foleg opensource cucc), ami nem volt a taroloban.

A PKGBUILD szemelyre szabasanak hianya meg nem jelenti, hogy nem forrasalapu. Gentoo alatt sem tudsz belenyulni az ebuildok lelkivilagaba azon tul, amit a csomagkeszito megalmodott. Ha pl. nincs olyan USE flag, amire neked szukseged lenne, akkor csak kerulo uton, vagy az ebuild meghackelesevel tudod elerni a celodat. Az AUR ilyen szempontbol legfeljebb lebutitottnak tekintheto, hogy meg USE flagekre sincs lehetoseg.

De ettol fuggetlen elfogadom az erveidet, hogy nem forrasalapu. Nekem mindenesetre ez volt a benyomasom rola, foleg hogy a makepkg asszem alapertelmezetten telepul. A binaris disztrok nem szoktak ennyire direkt modon tamogatni a csomagkeszitest, ott altalaban kulonbozo metacsomagokat kell felvarazsolnod, hogy meglegyen minden eszkozod.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Arch alatt viszont egész korlátozottak a lehetőségeid - gyakorlatilag semmi sem testreszabható ezen a téren, csak a CFLAGS jellegű dolgok.
Sok bináris disztró is támogatja a csomagkészítést, ott is csak egy-két csomagot kell feltelepíteni - sőt, amennyire emlékszem, az AltLinuxban nagyon sok spec-fájl (rpm) feltételekkel van elkészítve (azaz egy rpmconfig fájlban megadhatod, milyen "use-flag-eket" akarsz) - fényévekkel jobb helyzet, mint az Arch-féle PKGBUILD-ek :)

Osszes "webfejlesztes" amit csinalok, a sajat honlapomon tortenik. (tortenne, ha nem lennek alulmotivalt) Az egesz blogmotorom egy 60 soros shell script. (RSS generatorral egyutt).

szerk: a "sosem PHP"-t nyomtam, de lehetett volna a "nem ertek..." is. Mindkettot vallalom.

--------------------------------------
Unix isn't dead. It just smells funny.

( Dacr (nem ellenőrzött) | 2013. 09. 20., p – 10:09 )

Egyéb: ez feladatfüggő. Van, amihez eszem ágában nincs behúzni egy keretrendszert, mert felesleges, és természetesen van az project, amihez már elengedhetetlen egy egységesített környezet.

( Luther | 2013. 09. 20., p – 10:30 )

Nulláról írt PHP kódra szavaztam, a legfőbb okom, hogy soha nincs két egyforma igény, minden eset eltérő.
A másik pedig, hogy könnyebb hibát javítani, hiszem amit én írtam, annak jobban átlátom forrását.
--------------
“If there were no hell, we would be like the animals. No hell, no dignity.”

( Mcsiv v | 2013. 09. 20., p – 11:05 )

Egyszerubb dologra gondolkozas nelkul php, bonyolultabb dolgokra is, csak akkor mar szoba jon mas is. Mostanaban perverz kotodesem lett a c/c++ iranyban:)

// Happy debugging, suckers
#define true (rand() > 10)

( kovarik | 2013. 09. 20., p – 11:15 )

Én vegyesen használok frameworkot és CMS-t. Az ügyféligénytől függ. CMS esetén Drupal, framework esetében pedig jelenleg most a Yii a favorit.

Padig van. Büszkeséggel tölti el az embert, hogy a saját keretrendszerén fut valami hibátlanul, és ha mégsem hibátlan, könnyebb a hibakeresés. Lassan 2 éves lesz a CMS-em, és számos lehetőséggel bővült az eleje óta, és már jó pár projektet sikerült vele elkészítenem. Hát nem király dolog? :)
---
Ássuk el a csatabárdost!

"könnyebb a hibakeresés"

Én ebben nem lennék olyan biztos.

Ha egy népszerűbb, sokak által használt keretrendszert használsz, akkor ideális esetben csak a saját kódodban kell a hibát keresned. Ha saját keretrendszered van, akkor azt is túrhatod. Nem mondom, hogy nem lehet hiba a külső keretrendszerben, de azért gondolom nagyobb eséllyel derülnek ki (és kerülnek javításra) hibák egy olyan rendszerben, amit rengetegen használnak, szemben egy olyannal amit csak te magad.

Én még mindig azt látom, hogy tanulásra kiválóak ezek a rendszerek, de a legtöbb lassan saját kis programnyelvvé válik, ami néha felesleges. A másik, hogy ez a kérdéskör előjön a házi barkács vs. készen veszem témakörben is, van aki egyszerűen csak szereti csinálni, főleg ha picit mást kell, mint amit már tud mondjuk a yii.

( bri | 2013. 09. 20., p – 12:30 )

Nyilván attól függ, mit kell csinálni. Mindenhez azt, ami arra való. Az első 5 lehetőség mindegyike előfordul. Értelemszerűen az egyébre nyomtam.

alias killall='echo "Wenn ist das Nunstück git und Slotermeyer? Ja. Beiherhund das Oder die Flipperwaldt gersput." | espeak -vde' #That's not funny.

( hans1985 | 2013. 09. 20., p – 16:23 )

Egy válaszban nem lehet ezt megmondani, de többen igen:

Mini feladatra:
- "Nulláról írt PHP kódra", de ez sem igaz, mert ilyen olyan library akor is van, de nem egy full fw.

Egyszerűbb oldal:
- Ez is feleadat függő, "Nulláról írt PHP kódra"+library-k vagy "Egy web framework-re (Zend, Symfony, Yii stb.)" nálam ez Codeigniter.

Közepes és nagyobb oldal:
- "Saját építésű framework-re / CMS-re (felhasználva / módosítva más framework / CMS kódját)"

----

Joomla vagy Drupal vagy hasonló állatformák kizárva! :)

________________________________
blog: http://horvathjanos.wordpress.com

( cherockee v | 2013. 09. 20., p – 16:40 )

Saját framework, aminek az előnye a meglévő framework-ökhöz képest az alábbi három:

- saját elgondolás (egyben hátrány is lehet), de gyors a hibakeresés, módosítás, főleg a kisebb módosításoknál nagy előny

- nem sok framework-öt láttam, ami tényleg nagyon egyszerűvé tette webapp-ok fejlesztését (gondolok itt arra, hogy nyilván nem a php dolga a UI-t kezelni, de sokszor nem ártana, ha a várható felhasználás oldaláról is megnéznék, hogy az úgy jó lesz-e)

- amiket próbáltam framework-ök legjobban lecsupaszított állapotban is iszonyat vastagok voltak, nem láttam jól darabokra szedhető rendszert (fix me), viszont az esetek nagyrészében a funkciók jóval kevesebb mint felét kellett használnom, a többi viszont bonyolította a kódot, növelte a futásidőt, ...

Ha valaki tud olyan framework-ről, ami friss webapp fejlesztésre jött létre, akár kezdetleges formában, szóljon. Amit nem igazán találok, az a sablonkezeléstől az adatbázisig egy jó átfogó elgondolás, amiben nem kell kézzel kötögetnem az ajax-os UI-t, meg az adatbázist, gyorsan lehet prototipizálni, és tényleg elég csak azt behúzni, amire szükségem van, nincsenek iszonyat nagy függőségek.

szerk.:

az meglep, hogy van aki nulláról írja a programjait, legalább a meglévő cuccait nem szervezte egy kezdetleges framework-é össze.

Én a Laravelt használgatom, amikor nem tudom megkerülni egy fw használatát.
Egész jó a doksija, nem mondható nagyon lomhának, viszont a 4. kiadás óta 100mega alaphangon, mivel behúzták a symfony egyes komponenseit. Ettől függetlenül még mindig nem rossz (arra, amire én használom).

( zsoltee | 2013. 09. 20., p – 18:20 )

Ha rám van bízva, mostanában a Yii mellett döntök. Ad egy kényelmes keretet, nem korlátoz túlságosan, logikus és kellően gyors.

( Elbandi v | 2013. 09. 20., p – 18:53 )

irigylem azokat az embereket, akik sajat fw irasakor akkora kodminoseget tudnak produkalni, mint amit sok 10 ember egy-egy frameworkben/cms-ben... :/

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

sajnálom azokat az embereket, akik nem tudják megérteni az alábbi két gondolatot:

- van, aki saját maga szereti megoldani a problémát. attól, hogy van rá megoldás, még lehet élvezem ha foglalkozok vele. lásd rubik kocka, megnézheted youtube-on, hogy hogy kell kirakni, na most boldog vagy? nem mellesleg, hogy a fenébe tanulja meg valaki a programozás alapjait, ha elétolsz egy framework-öt? ha mindenki a meglévőt használná, akkor nagyon sok vadhajtásnak induló, "nekem van egy kicsit más ötletem" rendszer ma nem létezne, minek is volt szükség facebook-ra, amikor már volt myspace? vagy minek van szükség linux-ra, ha már van bsd?

- van olyan irány, gondolatmenet, ami még nincs a mostani framework-ökben megvalósítva. ezeket is azokba kéne beleeröltetni, mert hülyeség is máshogy csinálni?

Ironizálok is, meg nem is.
Utálom a PHP-t, de sok helyen használni vagyok kénytelen. Sok jó cucc van, ezek zöme PHP-ban íródik - pl. Zabbix, DokuWiki, SmBind - a teljesség igénye nélkül.
A Joomlát említettem, mert azt használom. Régebben próbáltam a Drupalt is, de nem állt kézre.
Nem mondom, hogy rengeteget programozom, főleg PHP-ben nem, de belenyúlok, ha muszáj, és ezt a belinkelt kiegészítőt azért töltöttem le, hogy lehessen vicces modokat csinálni - de még nem próbáltam ki - amúgy tényleg horror, főleg, ha van benne valami exploit, és Iván lecseréli a kódodat az övére :)
--
PtY - www.onlinedemo.hu

Nem baj. Annak baj, aki a BSD-t megalkotta, és nem ő él(t) belőle úgy, ahogy más.
Ezért tekintem az Apple-t és a M$-t is nettó tolvaj bandának, mert más munkájából élnek.
Talán úrbánlegenda, de az MS-nek még saját IP stack-je sem lenne a BSD nélkül (include bsdsocket.h - sztori).

És itt most ezt ne úgy értsd, hogy a BSD-t hibáztatom, olyan a licence amilyen, nem lényeges. Viszont az, hogy van a Linux, ami a GPL licencre épül, mindenképpen hasznos az ilyen kreativitás-tolvajbandák ellen. És a kérdés az volt, hogy minek Linux ;)

--
PtY - www.onlinedemo.hu

Egy picit mást értünk tolvaj alatt: aki elveszi, ami nem az övé. viszont a bsd public domain*, ez nem lopás. az, hogy ebből lettek gazdagok, az meg kicsit ferdítés, mert azért nem a FreeBSD x.x-et rajzolták át, elég sokat dolgoztak rajta, hogy olyan legyen amilyen. Vagy nem?

Sokkal kevesebbet dolgoztak rajta ahhoz viszonyítva, amennyivel több jelentkezett profit oldalon :)
És más az, amikor úgy alakítok át valamit, hogy utána azt elérhetővé teszem...
Igen, mást értünk tolvaj alatt. Aki MKV-t készít a BluRay discről, is sokat dolgozik vele, haszna nincs belőle, ám mégis bűnözö... Vesd össze.
--
PtY - www.onlinedemo.hu

a bluray lemezre rá van írva, hogy kié, és hogy nem szabad másolni, a BSD kódjára meg rá van írva, hogy nyugodtan másold, add el, módosítsd.

abban meg közel se lennék biztos, hogy kevesebbet dolgoztak rajta. gondolom neked a marketing, a szervezet felépítése és fenntartása, a support, a UI/UX, a kód további fejlesztései, az teljesen mindegy is, 2 perc alatt megvan. jó dolog az opensource, de ha egyszer betartották a játékszabályokat, akkor mi is a probléma? az hogy nekik sikerült...

Nem érted az összevetést - megpróbálom elmagyarázni.

1. Ingyen szerzi (jogosan), módosít rajta, meggazdagodik belőle - hozzátéve, hogy mellette döngeti is a mellét, hogy mekkora király.
2. Megvásárolja, módosít rajta (jogtalanul), nem keres rajta semmit - hozzátéve, hogy nem tartja magát ettől király csávónak.

Részemről az első nagyobb tolvaj, és még képmutató is. Jogi értelemben meg a másik a tolvaj. Erkölcs vs. jog - tudom, nincs összhangban, de erre próbálok rávilágítani.
Nem muszáj evvel egyetérteni, mert ez egy vélemény, de ne is csinálj úgy, mint aki nem érti, hogy miről írok, mert az nem vezet sehová szerintem - max. flame lesz belőle.
--
PtY - www.onlinedemo.hu

Így már értem mit akartál, csak almát hasonlítasz szerintem körtével. De értem a hasonlóságot. És nem, nem csinálok úgy, mint aki nem érti, és elfogadom, hogy vélemény.

Csak azt nem értem, hogy szerinted mi lett volna a korrekt az Apple részéről? Bemutatják, hogy BSD-re építkezünk? Szerintem a közönségük 99%-ban lesz@rja, a UI, és a feature-ek érdeklik őket.

(Hozzáteszem: az "egyszeri kis kalóz" története ott bukik, hogy a legtöbb torrent oldal iszonyat pénzeket kaszál a hirdetéseken, arról nincs infom, hogy visszaosztanak-e a release-eket készítők közt, el tudom képzelni, hogy tényleg ingyen csinálják. Szerintem ettől még nem jobbak.)

Csakhogy a vélemény butaság. A BSD licenc kimondja, hogy azt csinálsz a kóddal, amit akarsz, akár céges termékben is felhasználhatod.
A szerzők választották a BSD licencet, pontosan tudva, hogy bármikor jöhet egy cég, aki felhasználja az ő kódjukat, és saját terméket
csinál belőle, vagy felhasználja a termékeiben. Az MS-nek (és más cégeknek) semmilyen trükközést ez nem jelent, ráadásul nem csak a GPL-nél
adnak vissza a közösségnek, lásd apache licencel futó rakás java library, ahol cégek hibajavításokat, céges supportot, fejlesztéseket raknak
bele, mégsem kell kiadniuk a teljes termékük forráskódját. LPGL dettó..

"Csakhogy a vélemény butaság."
Ez meg hogy? :)
Véleményrendőrség is lesz? Van rá 1984 okod?

Az, hogy Neked más a véleményed, az egy dolog, én sem mondanám rá, hogy butaság. Ha tényként közölnéd, az más dolog.
Szerintem senkinek semmi jogalapja arra, hogy bírálja mások véleményét. Ellenvéleménye lehet, de minősíteni nem kéne...
--
PtY - www.onlinedemo.hu

Semmilyen erkölcsi értelemről nem lehet beszélni szerintem. A BSD licenc szándékosan lehetővé teszi azt, hogy a BSD licenc alatt megjelenő
kódokat saját termékben felhasználd. Ez nem az MS/Apple/garázscég trükközése, amit erkölcsi alapon el lehetne ítélni, hanem az adott könyvtárat
készítő fejlesztők akarata, ők engedélyezték ezt, tehát én nem látok semmilyen erkölcsi alapot arra, hogy elítéljük őket. OpenBSD-esetén:

"includes the ability to REUSE most parts of the OpenBSD source tree, either for personal or commercial purposes."

Még csak az sincs, hogy a bsd licenc alatt fejlesztők erre nem gondoltak, és a nagy gonosz cég/pistike kitrükközte őket, ők szándékosan megengedték ezt...

Ez kész. :DD
"Semmilyen erkölcsi értelemről nem lehet beszélni szerintem." - Majd jön a jogi vetületű rizsa, ami már fentebb szerepel 200-szor, és amire már 200-szor írtam, hogy ez a reésze rendben van.
Vedd már észre, hogy miről beszélsz Te, és miről én.
--
PtY - www.onlinedemo.hu

Miért? Mert nem tartom akkora nagy számnak azt, amijük van azért, mert az alapját nem is ők csinálták? Mire az a nagy hype körülöttük? A saját rendszerüket kidobták a kukába, és inkább a máséból villantanak? Ez vicc... És ez az, amivel bajom van. Igen, jogilag rendben van, csak épp más téren nem.
Erre van a mondás, hogy más tollával...
--
PtY - www.onlinedemo.hu

Natehát, kezdjük elölről. Te valami kifacsart erkölcs miatt próbálsz ekézni X/Y operációs rendszereket, akik teljesen törvényesen, szabályosan, ráadásul az adott
könyvtárakat létrehozó fejlesztők akarata szerint jártak el. (és ha már itt tartunk, remélem open source drivert használsz az nvidia/ati kártyádhoz, nem a bináris
blobot, ami már sokkal inkább a licencszerződés kijátszásáról szól).

Azért, mert egy cég egy szabadon használható könyvtárat használ - teljesen törvényesen - nem lesz se rossz, se jó. Valószínűleg ha nagyon akartak volna össze tudtak volna dobni egy TCP/IP stacket, viszont miért tegyék, ha azt mások már megcsinálták, karbantartják, javítgatják, és ráadásul simán fel is tudják használni - minden szempontból helyénvalóan.

Erről szól a BSD (és pl a java fejlesztők által előszerettel használt apache) licenc, de még itt van az LGPL is, ami majdhogynem hasonló szabadságot ad a céges fejlesztőknek.

A hype dolgot se értem igazán, mind az MS, mind az Apple sikeres operációs rendszert rakott össze, amit a felhasználók - legalábbis a statisztika alapján - előszeretettel használnak. A desktop linux évére pedig már jó ideje várunk, ott van minden, ami kell, de eddig valahogy mégsem sikerült elérni ...

Hol kifacsart erkölcs az, hogy valaki 0-ról épít rendszert, és szerényen mondja jónak (ld. BSD), más meg ezt használva (jogalappal értve), döngeti a mellét, és ez utóbbit nem tartom akkora nagy számnak? Szerintem ez csupán egészséges értékítélet. Első esetben teljesen jogos a büszkeség, másik esetben meg visszás kissé - csupán ennyiről beszélünk.
A 2. versenyző más tollával ékeskedik, ha joggal vette át, ha nem. Innentől más szellemi tulajdonán keresztül tett előnyre.
Csak ennyit kéne megérteni, de látom, hogy nem sikerül :)
--
PtY - www.onlinedemo.hu

Na nem hinném hogy az apple az alap miatt döngeti a mellét, hanem amiatt, amit ráépítettek. Azt meg ők csinálták, erkölcsileg se kifogásolható. Az meg, hogy felhasználtak egy kész rendszert alapnak miért baj? Ha én felhasználok (egy fizetős weboldalon) egy keretrendszert, akkor én rossz vagyok?

az, hogy nem tartod akkora nagy szamnak, az egy "who cares?" kategorias velemeny. Az, hogy tolvajnak allitod be oket, (csak mert eltek a bsd licence adta lehetosegekkel, amit annak keszitoi biztositottak barki szamara), az meg nem gyenge ordas ragalom, valoszinuleg a licence nem ertesebol fakadhat.

Az hogy van hype vagy nincs hype, ez erosen szubjektiv dolog, engem finoman szolva hidegen hagy. Csakugy mint az, hogy szamodra vicc, hogy a masebol villantanak. Most oszinten, ki nem szarja le, hogy szamodra mi vicc vagy nem? A ket ceg ill. azok csillionyi juzere tuti, es itt a vege a dolognak. A mas tollaval mondasod is kb. a licence nem ertese, ill. annak elmismasolasa, hogy azert a 2 melitett OS boven tobb, mint egy tcp/ip stack.

--
"Pontosan ez a ti bajotok. Ez a kurva nagy csőlátás. [...]" (bviktor)

erkölcsi értelemben -, amit Te jogilag próbálsz felfogni. Wake up,

mokas az, amikor megprobalod nekem megmagyarazni, hogy en mit es hogyan gondolok. Csak szolok, hogy megertettem elsore is, hogy a te erkolcsi erzeked zaklatta fel a dolog, de aruld mar el, mi a te erkolcsod forrasa? Ez valami karma dolog, vagy mi?

--
"Pontosan ez a ti bajotok. Ez a kurva nagy csőlátás. [...]" (bviktor)

"mokas az, amikor megprobalod nekem megmagyarazni, hogy en mit es hogyan gondolok."
Ha a BSD licenccel érvelsz, azt minek neveznéd? Az tisztán jogi vetület. No comment.
Az meg, hogy engem irritál, ha valaki más farvizán jut előnyhöz, szubjektív dolog, ne próbáld az ellenkezőjét bizonygatni, mert semmi értelme.
--
PtY - www.onlinedemo.hu

Ugyanonnan, ahonnan a Tiéd. Egy rész veleszületett, egy rész felszedett az évek során - mindenkinél más az arány, és más az irány. Valakién van almás logó, valakién nincs. Valaki nem szíveli, ha más teljesítményét az ő sikerének ítélik, valaki nem.
Valaki elnézi ezt másnak, valaki nem.
Te vajon hová tartozol? ;)
--
PtY - www.onlinedemo.hu

"van, aki saját maga szereti megoldani a problémát. attól, hogy van rá megoldás, még lehet élvezem ha foglalkozok vele."

Ez becsulendo, egy hobbi projektnek. A kezedre csapnak ha ilyet productionben akarsz csinalni. (kerdezd meg magadtol hanyszor irtal erre az elvezetbol megoldott feladatra teszteket, mekkora volt a code coverage, es mennyire kellett babralni a core-jat amikor egy uj, latszolag userspace requirement felbukkant)

"van olyan irány, gondolatmenet, ami még nincs a mostani framework-ökben megvalósítva"

Mondj peldat legyszives, szerintem te arra gondolsz hogy nincs egy cms-ben megvalositva (de majd a peldabol kiderul). A framework nem a te otleteidet valositja meg, hanem eszkozoket ad gyakran elofordulo problemak kezs megoldasara, ami hianyzik azt meg mindig megoldhatod magad, a tobbihez meg eldontheted hogy akarod e a framework segitseget kerni vagy nem.

production, testing, code coverage: nem vitatom, hogy erre szükség van, sőt. azt írtam csak, hogy "van, aki...", vagy van, amikor. de egyről beszélünk, ez nem a tömeges felhasználásra felvetés, hanem az újszerű fejlesztésekre (részben újra validálnom kell a véleményem, eddigi tapasztalatom az volt, hogy berántott a rendszer egy iszonyatos nagy overhead-et, ami biztos jól jön majd, de nem skálázható vissza...ezt viszont nem ma néztem utoljára, mostanában ahogy látom pont előrelépés van ezen a fronton)

irány, gondolatmenet: pontosítok, ezt speciel a CMS-ekre mondtam, visszaolvastam, nem voltam pontos. a framework-re ezt nem tudom mondani, esetleg egy-egy framework által eröltetett modellre-felépítésre, de ott meg egyszerűen másikat választok

nem azt mondtam, hogy mindent magam csinálok, direkt ezért kezdtem úgy, hogy "van, ...". nem mondtam azt sem, hogy ugyan olyan jó lesz, és részletes, és majd egyedül lenyomom a laravel teljes feature készletét. azt mondtam, hogy van az a feladat, amit lehet én máshogy oldanék meg, ahogy ők oldották meg (nem jó példa, mert főleg a CMS-ekről beszélek, kevésbé a framework-ökről)

Nem feltétlen. Mint ahogy nem te írod meg az oprendszert fordítóval, a fájl-szerkesztőt és a php-értelmezőt/futtatót sem a php programozáshoz.
De házépítéshez pl. a téglát "méretre" vághatod, az autóba való gumicsőből egy darabot levághatsz.

Van egy szint, ami "alatt" inkább a már készre ("mesteremberre") hagyatkozol, és ami "felett" inkább saját magad csinálod. Ez a szint mindenkinél más és más (ízlés, idő, kedv, stb. kérdése) - pl. én szeretem, ha a féket én húzom meg a biciklimen, de egy kollegám azt mondja, ő egy csavart sem húz meg rajta, elviszi inkább szerelőhöz és kiad érte X összeget.

Pedig sajna ez nem ritka, hogy vki magat XYZ programnyelven kvazi gurunak nevezi, aztan kiderul, hogy egy specialis IDE-ben tud csak dolgozni, adott framework nelkul hozzaszolni sem tud a temahoz, stb, esetleg csak ossze tudja "huzkodni" az objektumokat vmi GUI varazsloval vagy mi a fenevel ... Ez a szomoru.

Igen. "nem mellesleg, hogy a fenébe tanulja meg valaki a programozás alapjait, ha elétolsz egy framework-öt" es hasonlo gondolatokrol jutott eszembe, hogy sok mai magat top progamozonak nevezo entitas valojaban csak egy IDE-hez/framework-hoz stb-hez ert, es ha barmit nullarol kene fejlesztenie, meg lenne love.

ezt részben én is így látom, inkább úgy mondom, hogy nem nagyon van kapcsolatuk a felhasználókkal (lehet ez önként választot, vagy rejtet hiba is), és ezért nem tudják milyen valós problémákat kell megoldani

én ezért nemlátom némelyik CMS-ben, hogy mire jött létre, vagy mit csinál egész pontosan

( uid_17626 | 2013. 09. 21., szo – 08:44 )

Ha webfejlesztésről van szó PHP-ban, akkor mire szeretsz építkezni?
(X) A tudásomra :)

( hrgy84 | 2013. 09. 21., szo – 09:36 )

Lehetoseg szerint nem megyek PHP kozelebe. Nem vagyunk olyan jo baratok.

Ha megis kozelebe kell mennem, akkor feladatfuggo. Ha alapvetoen tartalomkezelesrol van szo, akkor CMS, ha nem, akkor valami framework, akar a cegen belul fejlesztett sajat framework, akar valamilyen altalanosabb. Nincs kedvencem jelenleg, bar a Symfonyval tervezem megismerkedni.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

( wachag | 2013. 09. 21., szo – 14:12 )

Akármiről van éppen szó mellettem, én a legjobban szikla alaptalajra szeretek építkezni. Az stabil.

( pezia | 2013. 09. 21., szo – 20:07 )

Feladatfüggő. Drupal vagy Symfony 2.

( nikin v | 2013. 09. 22., v – 09:45 )

Saját "framework/CMS" részemről. Aminek a fő fejlesztési iránya (a szerintem méltánytalanul elhanyagolt) rendszerigény minimalizálás. Még erősen fejlesztés alatt, és leginkább azt tudja, ami nekem (és a megrendelőimnek) kell.

### ()__))____________)~~~ #################
# "Ha én veletek, ki ellenetek?" # E130/Arch

Az a helyzet, hogy ez nem ilyen egyszerű.
Jelengleg : egy oldaltöltés valahogy így lakul:

minimális tartalom : 0.0215s 512 kbytes
közepes tartalom egy nagy táblázat 12x900 : 0.2724s 1792 kbytes
nagyobbacska tartalom : 0.0624s 512 kbytes

Ez egy 1.2 Ghz-s procin soft-raid1 -el. közel minimális load mellett.
Egy 1.8-as procin SSD-vel 5-öd ennyi az idő.

De nem gondolom, hogy ez anyival jobb lenne mint mások kódja. Egyszerűen másra van kihegyezve.
Funkcióban köze sincs, egy akár közepes CMS-hez, vagy framework-höz.
Nem nyújtja azt az MVC szeparációt sem. Satöbbi. De számomra egy jó (és egyre bővülő (modulokkal)) alap amin gyorsan meg tudom csinálni amit szeretnék, ami kicsi-közepes terhelés mellet kb. bármin elfut. Pl. a CMS képességei eléggé kezdetlegesek, mert leginkább alkalmazás készült vele eddig. De a több-nyelvű oldalak támogatása alap funkció. Ami máshol gyakran csak 5 modul bekapcsolásával működik.

Szóval rossz szavam sincs mások munkájáról. Egyszerűen nekem jobban beválik a saját. Ez szerintem ember-típus kérdése.

### ()__))____________)~~~ #################
# "Ha én veletek, ki ellenetek?" # E130/Arch

"(a szerintem méltánytalanul elhanyagolt) rendszerigény minimalizálás"

Én is ezért gondolkodom saját cuccokban. Fentebb írta valaki, hogy egy fw 100M fölötti. Mégis minek? én bőven megvagyok a ~800KB-os adatbázis object-tel és alap html struktúrával, az oldal többi része úgyis laponként más, és más.

Minket arra biztattak a suliban, hogy ha valamit meg kell oldani, akkor arra először csináljunk saját megoldást, majd ha nem sikerült, csak akkor nyúljunk framework-höz. Manapság meg mindenhol csak a frameworköket nyomatják, és halvány fingjuk sincs az embereknek a saját megoldások kialakításáról.

Ugyan ez igaz a CMS-re is. Néha totál feleslegesen zabál meg erőforrást a semmiért. Arról persze szó sincs, hogy nincs szükség rájuk, csak értelmetlenül nagyra nőttek. Persze megtanulom akármelyiket, ha kell, de magamnak nem használom egyiket sem.

(más a js framework, mert azt használom, de csak mértékkel...)

--
openSUSE 12.2 x86_64

1, Yii framework kb. 10 mega helyet foglal el. A többi framework is nagyságrendileg ennyit. A tárhely a világon a legolcsóbb dolog.
2, Nem tudom, milyen suli volt az, de szerintem butaságot beszéltek. A lehető legdrágább a fejlesztő munkaideje. Ha minden egyes kis projektnél saját frameworkot kezdesz írni, akkor az iszonyatosan drága lesz, ráadásul sok időbe fog telleni. Egy egyszerű honlaphoz bőven elég feldobni egy wordpress-t, csinálni egy style-t, feltölteni a tartalmat. Van hozzá minden, amire egy átlag megrendelőnek szüksége lehet. A security frissítések automatikusan történnek jobb esetben, nem kell a maintenance-al szórakozni, sőt, ha megfelelő neki, akkor fel lehet rakni olyan helyre, ahol ezt évi pár $-ért automatikusan megoldják. Ha sok-sok content van, akkor érdemesebb nagyobb ágyúval lőni: drupal és társai a barátunk. Ha teljesen egyedi fejlesztés kell, akkor ott vannak a fent említett php frameworkök, amik nagyon sokat segítenek, hogy a trágya php-ben egészen kulturált kinézetű, moduláris kódot tudj írni. Itt is nagyon sok mindent alád raknak, hogy neked tényleg csak a termék fejlesztéssel kelljen foglalkozni. Ha aztán valami űberspeciális helyzet van, akkor érdemes saját kódot 0-ról írni, akkor, ha az ember tudja, hogy mit miért tesz.
3, Addig volt a gond, amíg mindenki saját kódot hegesztett, aztán át kellett venni másnak a "zseniális" munkáját, és a vége sokszor az újraírás lett. Ezen talán valamennyit javítanak a framework-ök.

Szerintem lajos arra az elvre gondolt (amit amúgy valahol jogosnak érzek), hogy akkor használjon valaki framework-öt, ha olyan szinten van a tudása, hogy ha nagyon muszáj lenne, meg tudná ő is oldani. Amiben van logika, mert így 1) ha a framework eltűnik [befejezik a fejlesztést, akármi] akkor sincs meglőve és nem függ a framework-től 2) legalább felszínesen ismeri a belső működését stb. De nem jelenti azt, hogy írjunk meg mindent, mindig újra. Csak tudjuk, mit csinál és miért, a hogyant bízzuk rá.

Egy nagyon egyszerű példa: tanítanál Hello World szinten programozást úgy, hogy akkor írjunk HTTPServlet-et? Nem, mert alatta van egy teljes "keretrendszer", ami kezeli a hálózatot, fogadja és feldolgozza a lekérdezést, reflectionnel előállítja a Servlet példányt (*), aztán a Servlet kimenetét visszaküldi a hálózaton a kliensnek (**).

Ez alól persze vannak kivételek, amikor nem kell feltétlenül ismerned az alsóbb réteget (tipikus példa: crypto cuccok), de sok "kényelmi" absztrakciós rétegnél nem árt legalább felületesen ismerni az alatta levő dolgokat (pl. lehet használni egy mailer osztályt anélkül, hogy valaha hallottál volna az SMTP-ről, csak akkor lesz baj, amikor először kiderül, hogy a leveled a spam-be landolt és rá kéne jönni, hogy miért)

*: Ok, lifecycle is van...
**: azt most így első nekifutásra passzolnám, hogy a standard szerint és tetszőleges konténernél a Response-ban levő OutputStream közvetlenül a Socket OutputStream-je-e, vagy bufferbe dolgozik. Viszont elég jó tippem lenne arra, hogy hol kell keresnem, és bár elrejti előlem a FW, van, hogy tudnom kell.

BlackY

Nem azt mondtam, hogy minden apró cucchoz saját framework kell. A nagyobb kaliberű cuccokat célszerűbb egy csak arra kihegyezett frameworkkel csinálni.. Tapasztalat Wordpress vs. saját cucc: a wordpress betöltése ~1.5sec (alig pár cuccal), saját cuccé ~0.5sec telipakolva...

Azt könnyen kilehet jelenteni, hogy tárhely így meg úgy. De gondolom tudod te is, hogy ha valaki valamit nagyra csinál, sok látogatónak, akkor ahhoz kell vas is, nem elég egy szottyos tárhely amin pistike kalapálja a szarát. Márpedig ha saját vas kell, akkor az nem két fillér, ezért ott kell optimalizálni ahol csak lehet: visszakanyar az adott projektre kihegyezett frameworkre... Ugye azt tudod, hogy az a 10 mega az futáskor a memóriába is 10 mega? 10 usernél még nem gáz, de 100.000-es látogató környékén már zavaró lehet, márpedig nem 10 látogatóra fejleszt az ember, vagy te igen?

A "mindennek állj neki te magad" pedig nem hülyeség. Ez ösztönzés, hogy "ugyan má', álljmá' neki és tanuld má' meg rendesen!", és talán nem csak taknyolni képes programozók jönnek létre...

--
openSUSE 12.2 x86_64

Akkor sajnos mégsem értek egyet veled :)

Elismerem, hogy van egy határ, ami felett skálázhatóságban már a saját célzott rendszer felette van az általános célú keretrendszerekből kiszedhetőének, de azért nem 10 usernél (még talán a 100000 sem gond, bár nem írtad mennyi idő alatt :) ). Ráadásul lehet olcsóbb újabb szervert üzembe állítani, mint megfizetni a programozót, aki megcsinálja a specializált keretrendszert.

Amúgy meg azért a legtöbb keretrendszer/library/stb. többnyire elég jól optimalizált (nem úgy értve, hogy nincs felesleges változóértékadás, hanem, mivel többen fejlesztik és van rá emberidő, a hatékonyabb, de hosszabb kódból álló algoritmus van mögötte) és a legtöbb esetben még mindig olcsóbb használni egy FW-t és teljesítményproblémakor profile-rrel megnézni, hol a gond, azt a részt átírni, mint mindent nulláról írni, tesztesetekkel lefedni, összes ráépülő projektbe a fejlesztéseket/javításokat visszaportolni stb.

BlackY

őőhm, lehet, hogy nem értesz. Túl bonyolultan gondolkodom néha és nem tudom megfogalmazni :) Szóval, az volt a gondolatmenet, hogy egy apró weboldal, cms-sel osztott tárhelyen eldöcög 10-100 egyidejű userrel. Ezzel szemben egy nagyobb, 100-500.000 egyidejű látogatóhoz már azért kell a saját vas is és a csak arra a feladatra fejlesztett framwork/CMS. szal: mint nagymama képtára vs. picassa...

A fejlesztők megléte ennél a szintnél már alapkövetelmény. Első körben azzal kezdtem, hogy van haszna a meglévő framworknek, cmsnek, egy bizonyos szint alatt.

Láttam már hogyan zajlik egy nagy, nemzetközi szinten működő weboldal fejlesztése, üzemeltetése.

--
openSUSE 12.2 x86_64

Ok, ugyanarról beszélünk.

Ha olyan, nagyteljesítményű weboldalt akarunk csinálni, amire egyidejűleg több 100 ezren mennek rá, akkor a skálázható architektúra a lényeg, mert ugye az nyilvánvaló,
hogy ezt nem egy géppel szeretnénk megoldani. Több adatbázis szerver, terheléselosztás, cache-ing, stb. De ez teljesen más kategória, mint amire a php framework-öket kitalálták, sőt, az sem biztos, hogy php-val kell nekiesni egy ilyen feladatnak. Mindent a maga helyén kell kezelni.

elvezet titeket olvasni, csak egy kerdesre nem tudom a valaszt: hany olyan magyar oldal van (ok, lajos22 nemzetkozi projektrol beszelt), ahol 100k paralel userre kell meretezni a cuccot? Csak mert ha nem sok, akkor az eszmefuttatasotok a sajat vs. bolti framework-rol praktikusan nem tul praktikus... :-)

--
"Pontosan ez a ti bajotok. Ez a kurva nagy csőlátás. [...]" (bviktor)

Félmillió ember? Egyidejűleg? Igen, nem lehetetlen mennyiség.

De hogy mit is jelent az emberben kifejezve:

http://hu.wikipedia.org/wiki/Index_%28internetes_%C3%BAjs%C3%A1g%29#L.C…

És ezek napi átlagok voltak. Egy itthoni viszonylatban már picit nagyobbnak számító webshop 10-100K egyedi látogatóval rendelkező oldal is mondjuk jelent másodpercenként 1-3 oldalletöltést (+ kiegészítő cumók). Ezt ma egy belépő szintű szerver röhögve kiszolgálja. Legyen mondjuk fél milla a gép és egy milla a hosting díja 5 évre. Mennyiért is fog valaki egy cég készíteni webshopot és azt folyamatosan fejleszteni? Töredéke a vas ahhoz képest.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Kevered a dolgokat. Az 500k egyideju latogato nem azt jelenti, hogy ez a terheles folyamatosan (7x24) ott van. Hanem hogy erre kell meretezni, mert a peak az ennyi. Lehet, hogy a nap 85%-aban nincs 10-20k -nal tobb latogato, de mittudomen este het es tiz kozott ennyi van. Es nem vicces, ha ennyi embernek HTTP 500-at dobunk az arcaba.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Azért az megvan ugye, hogy általában 2-3 nagyságrendenként változik az, hogy mi a nyerő stratégia?

De amúgy még mindig ott tartunk, hogy 100K *egyidejű* látogató, vagy az csak egy csúnya elírás volt részedről?

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

És remélem, az is megvan, hogy ha virtuális gépet tervez a peak-re, az még hagyján, mert az el nem használt erőforrást oda lehet adni másnak, de ha fizikait, az gáz.
Fel kell ugyanis mérni, hogy mekkora az esetleges peak hossza, továbbá azt is, hogy ha 100k user van (tegyük fel), akkor átlagos oldalmérettel az mekkora sávszélt jelent, mert b@szhatjuk az erős gépet, ha szűk a cső a végén ugye...
És egyáltalán megéri-e Xx100e HUF rááldozás arra, hogy alkalmanként 10-15 percre belassul a rencer...
Szóval óvatosabban kéne becsülgetni, mert nem minden a userszám... Ha van fenn a rendszeren egy 10Mbites kódolású fullhd video, és 100 (és nem 100ezer!) user nézi egyszerre, az megeszi a gigabitet úgy, mint a huzat, akármilyen vaskos cuccot rakunk alá. Ha meg csak 100Mbit a sávszél a colocationben, akkor már 15-20 user is anyázni fog.
Aki meg ezt nem érti meg, az így járt.
--
PtY - www.onlinedemo.hu

egyáltalán megéri-e Xx100e HUF rááldozás arra, hogy alkalmanként 10-15 percre belassul a rencer...

ha a konkurencia nem lassul be, akkor presztizsveszteseg, ha a tied igen, annak minden kellemetlen velejarojaval.

Az erdekes kerdes, hogy jobb-e 100k usert virtualis gepeken kiszolgalni, mint fizikai vasakon? Ha a 100k usert nem a hrgy84-i ertelemben veszed (100k user az adatbazisban, amibol kb. 1% aktiv), hanem az ertelmesebb megkozelitest (=100k user tolt le szimultan toled), akkor az valoszinuleg egy nemzetkozi erdeklodesre szamot tarto site, ahol szinten biztosan hullamzik a terheles, de garantaltan nem ugy, hogy 10-12 kozott csucs, aztan meg lablogatas, ill. az sem biztos, hogy megteheted, hogy nem a csucsterheles 2x-esere meretezed a cuccodat.

--
"Pontosan ez a ti bajotok. Ez a kurva nagy csőlátás. [...]" (bviktor)

[q]ha a konkurencia nem lassul be, akkor presztizsveszteseg, ha a tied igen, annak minden kellemetlen velejarojaval.[/q]
Ha a konkurencia feleannyi usert visz, akkor nem zavar a lassulás (nyilván függ a mértéke is). Aki a konkurenciát használja, nem tapasztalja, hogy nálam lassú, és viszont. Szóval sok érv van még, amit érdemes átgondolni, mielőtt az ember a fejlesztés mellett dönt.

Ha úgy tudod méretezni a virtuális gépeidet, hogy a szerverek terhelési görbéi ne essenek egy idősávba (és ez konkrétan nem a peak-ről szól), akkor egy virtuális környezetben sokkal több erőforrást tudsz kihasználni, mint fizikai környezetben.

VMware-nek van erre valami toolja (nem jut eszembe a neve), amit egy vállalati környezetbe be kell telepíteni, és monitorozza a szervereket, majd megmondja, hogy ha bevirtualizálod mindet, milyen erőforrásokat kell biztosítanod. HA-val is számol. Talán capacity planner a neve, de ne igyál rá mérget.
--
PtY - www.onlinedemo.hu

A user általában leszarja, hogy a konkurencián 10 vagy 100 felhasználó van, ha az megy..

Felesleges mindenkinek külön írnom, szal egybekapjátok.

Amikor számolok, akkor a felhasználókat egyszerre jelenlévőként számolom. Miért? Mert kerek számokkal könnyebb számolni és jóval a valós igény fölé lőve sosem ér meglepetés. Ugye nemzetközi oldalt nem lehet úgy tervezni, hogy helyi idő szerint délután 4 és este 8 közt van csúcsidő, mert egyéb országokban az eltérő idő miatt máskor van csúcsidő. tehát 24 órás csúccsal számolok. (lent leírom miért mindent nagyban gondolok...)

Na mármost szerver és sávszél nálam minden esetben a számolás része.(együttesen nálam ez a vas) Szal. Végig kell zörgetni, hogy a 100k user.. de tudjátok mit?.. számoljunk csak 100-zal. szóval a 100 darab user aktív a rendszerben, mindenki egyszerre teszi ugyanazt. Lássuk, 1 másodperc kell az oldal generálásához, mert túllőttünk a célon és lassú a CMS, ugyanakkor a végeredmény csak 100KB. Tehát az oldal generálása összesen ~100 másodperc és a sávszélességből elhasználunk 100*100KB*8 = 80Mb-et. tegyük fel van rá pénz és olyan gépünk van, hogy 0.001sec alatt generálja az oldalt, így már csak 1sec lesz a várakozás, de ugyanúgy 80Mb-et használunk a sávszélből. Közben ugye számolni kell azzal is, hogy ez mennyi memóriát vesz igénybe, mennyire terheli a merevlemezeket stb. tehát ha a CMS-ünk megeszik 10MB ramot felhasználónként, akkor ugye ez 1000MB lesz. ez csak a CMS, ehhez még ugye jön az OS, ami egyen mondjuk 2G ramot. Ok még csak 3 Giga ramnál tartunk, de ugye egyet értünk, hogy tárhely esetén az alkalmazás által megevett 1G RAM és 80Mb sávszél is sok, mert egyidejűleg akár 100 hasonló site is lehet azon a szerveren, és nyilván nekik is akkor van csúcsidejük, mint nekünk.

Jó. Jöjjön egy kis emelés, népszerűbb lett az oldalunk, mostmár csúcsidőben egyszerre 500-an vannak jelen.

egy joomláról lestem az alábbit:
Application 0.266 seconds (+0.004); 10.87 MB (+0.057) - afterRender
1 darab felhasználóval. Tehát 0.3sec a betöltési idő, és ehhez 11MB RAM került felhasználásra. Az oldal mérete 1.6MB

Szóval népszerűbb lett az oldalunk, aktív felhasználók száma 500 darab.
generáláshoz szükséges idő: 500x0.3 = 150sec, megevett memória 500x11 = 5500MB ~ 5.4GB, Letöltött adatmennyiség 500*1.6MB = 800MB = 6400 Mbit! Számoljunk 1Gbites nettel, akkor 6sec alatt töltődik le minden usernek, tehát 500 embernek ugyanazon tevékenységének kiszolgálásához 156 másodperc kell :)
Hol tudunk spórolni? van píz szerverre, vehetünk még vagy 2-t...
Ezért van szükség optimalizálni még akkor is, ha baszott nagy szerver áll rendelkezésre. Ha számolunk ennek a duplájával, tehát 1000 egyidejű látogatóval, akik ugyanazt töltik ugyanakkor, és ehhez méretezzük a rendszert, akkor nem lesz probléma ha csak 500-an vannak egyszerre... Felesleges ennyire felül méretezni?... mindenki döntse el maga.

Én úgy vagyok vele, ha már valamit csinálok, akkor azt úgy csináljam már az első programsor bevitelétől kezdve, hogy azt sok embernek csinálom, és lehet belőle népszerű oldal, 100.000 egyidejű látogatóval. Azaz megpróbálom a kódot úgy alakítani, hogy a lehető leggyorsabban a lehető legkevesebb erőforrást igénybe véve fusson. Tehát nem nyúlok 30x az adatbázishoz (mint a példában említett joomla) és nem húzok be 10-20megás frameworköt. Eközben fel kell találnom újra a kereket? és akkor mivan, ha a végeredmény jobb lesz mint az eredeti?

Ehhez kapcsolódik a fenti PHP-s vita. Hülye vagyok, mert PHP-t használok? lehet, de sokszor PHP-ben elég 2-5 sor ahhoz ami egyéb nyelveken 10..

--
openSUSE 12.2 x86_64

De könnyebb. Csak nem éri meg. Mondjam mi az aktuális projektem? 2 hét alatt csodát művelni. A feladat normális elvégzésére én kb. két hónapot tippelnék. (Meglévő rendszer részleges átalakítása és abból egy új felépítése.) A nem csináljuk meg nem opció.

Marad az, hogy két hét alatt megtesszük, ami kell az induláshoz, utána 2-3 hétben befejezzük, ami halasztható volt, de akkor már tud termelni az oldal (az alatt is) és ami legfontosabb: karácsonyi időszakra már bejáratott lesz. Maradék meg olyan, hogy ha szívás is lesz később átírni, nem előre lesz finanszírozva. Jelentős különbség.

Tervezhető az, hogy mekkora a várható terhelés, gép adott, a meglévő cumók mellett (röhögve) el fogja bírni anélkül, hogy egy percig is foglalkoztunk volna az optimalizálással. Az üzleti érdek most az, hogy működjön és jobb legyen, mint a konkurencia. Nem az, hogy 10 millisec-el gyorsabb.

Ja és ha az egész projektcsoport költségét kellene jellemeznem valahogy úgy nézne ki, hogy üzemeltetés + fejlesztők bére >> hosting/internet/villany > vasak :)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

savszel:
gziphandler, a tartalom tomoritve kozlekedik. plusz, nemhiszem hogy megabytok lennenek a HTMLek amiket kuldozgetsz, ha igen akkor ott valami gond van. Az egesz oldal lehet hogy lesz tobb MB de abban mar akkor kepek es minden kulso forras is bennevan, de azok kulon toltodnek le a browsered altal, nem pedig egyben.

memoria:
a peak usage azert nem minden, es nem minden memoria valos ram (virt), hidd el joval kevesebbet fogsz valojaban hasznalni mint ha csak a peakeket osszeadod.

Wordpress vs saját cucc: megint, arról beszélünk, hogy nem mindegy, hogy menyi időbe kerül egy fejlesztés, és amit ad, az elég jó-e. Ha egy sima egyszerű céges honlapról beszélünk, akkor arra lehet egy nagyon olcsó ajánlatot adni wordpress+sablon kombinációval, ami egy átlag felhasználó számára tökéletes élményt ad. És akkor ott van a karbantarthatóság kérdése, egyszerűen nem kell vele foglalkozni, két kattintás, és megvan az update (vagy jobb esetben autoupdate). Ezen a vonalon nincs is értelme versenyezni mással.

Amiről te beszélsz, az a hogyan csináljunk nagy rendszert, ami pedig egy teljesen más kategória.

"Mindennek állj neki magad" - nézd, én végigszenvedtem a java servlet, jsp, struts, struts2, ejb, ejb2, ejb3, play framework stb. vonalat. Ha az elején már olyan frameworkok lettek volna, mint most voltak, nagyságrendekkel jobb minőségű, karbantarthatóbb oldalakt írtam volna, lényegesen rövidebb idő alatt, kevesebb hibával. Ez egy természetes evolúció, rájöttek az emberek, hogy mik azok a megoldások, amik jók, és mi az, amit alapvetően el kell felejteni. Ha egy kezdő fejlesztőt berakunk kódolni, ő pont ugyanezeket a köröket fogja lefutni, ugyanezekkel a hibákkal fog szembesülni, és a végén nagyjából ugyanoda fog kijutni. Éppen ezért egy kezdő fejlesztőt nem engedünk saját engine-t kódolni, mert csak az időt pazarolja vele, ott a framework, oldja meg vele a problémáját. Aztán amikor már lesz sok tapasztalata, akkor álljon neki egyedit fejleszteni, tanulva az eddigi tapasztalatokból.

Viszont ha kezdetektől fogva a frameworkkel dolgozik, akkor soha nem fogja az alatta levő rétegeket ismerni, vagyis nem lesz tapasztalata. Fel lehet gyorsítani azt az evolúciót, amit leírtál, de teljesen kiiktatni szerintem hibás hozzáállás.

Hogy példát írjak: (nem production-be szánt orm rendszer) fejlesztés közben egyszer csak "nem működött" az instanceof operátor. Egy 


Obj bar = ...;
Class<Foo> foo = ...;
foo.isInstance(bar); // true
bar instanceof Foo // false

kód kellett ahhoz, hogy (egy örök életre) megtanuljam, hogy ... (ki mondja meg ránézésre? :) ). Ha egy ilyenbe belefut valaki, aki elől a nyelv ilyen mélységei el voltak rejtve, akkor azon kívül, hogy a Java specifikációt át kell néznie, még ott van egy teljes framework is, amiben keresheti a hibát.

BlackY

Igazabol teljesen egyetertek azzal hogy kene ismerni ami alatta van, de ha belegondolsz mi is csak valaminek a tetejet hasznaljuk akarmennyire alacsony szinten programozunk mondjuk javaban, vagy phpban vagy barmiben, hiszen az alatt meg van szamtalan mas reteg amit te se ismersz, lemehetnel akkor mar alatta levo c retegre (ha mondjuk phprol beszelunk) az alatt meg asm van, gepi kod, aramkorok es igy tovabb. Szerinted mindenki aki bedugja a halozati kabelt az tudja az osszes osi retegben mi tortenik? persze hogy nem. csak epitkezunk egyre magasabbra egyre tobb absztrakcioval hogy egyre kenyelmesebb legyen. Es ennek a kovetkezo szintje most hogy elobb utobb mar a frameworkot is ugy fogjuk kezelni (frameworkot, nem cmst) mint csak egy convenience layer

Értem, hogy mit írsz, és valamilyen szinten egyet is értek, én nem azt mondom, hogy nem kell érteni, hogy nagy vonalakban mit csinál a mögöttes framework, inkább
azt, hogy részleteiben nincs rá szükség, ha gond van, majd belemászol (nyilván a rizikó az, hogy nem biztos, hogy meg tudod javítani). A példa annyiból rossz, hogy
ha ilyennel találkozik az ember, akkor egy unit tesztet ír az adott helyzetre, aztán azt debuggolja, nem a teljes frameworköt.

Már fentebb írtam, ez arra volt jó, hogy megtanulja a kedves tanuló kompletten a nyelvet, hogy ne taknyoljon benne. Természetesen használtunk frameworköket is, főként js-hez, de közben azt is végig vettük, hogy amúgy azt hogy lehet megoldani natív kóddal...

--
openSUSE 12.2 x86_64

Van pár webshop a kezem alatt, abból az egyik egy kb. faék egyszerű és egy komplexebb. A komplexebbnél gondolkodtam múltkor néhány dolgon, hogy mit lehetne megcsinálni, hogy gyorsítsunk rajta. Aztán benchmarkoltam picit és arra jöttem rá, hogy a futásidő kb. 80-90%-a a PostgreSQL-re esik. Néhány százalékért lehetne faragni rajta itt-ott, de egyszerűen nem éri meg. Most egy kb. 2009-es 2xQuad Opteron gépen van 16G rammal. Ebből kihasznál átlag másfél magot. Néha felmegy 3,5-ig. Ahelyett, hogy szívatnánk magunkat, inkább le lesz cserélve a SATA RAID10 SSD-re, de még valószínűbb, hogy az egész gépet olcsóbban cseréljük.

Ameddig nem egy sok gépes rendszere van az embernek, ahol nem az SQL a szűk keresztmetszet, addig nekem ne magyarázzon senki arról, hogy a PHP-nek mennyi az erőforrás-igénye, ha arról van szó, hogy tegnapra kell, potom pénzért.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

90% SQL? Ez cache-elesert kialt. Meg mysql-ert ... :-)

Lassan 10 eve mar, hogy olvastam egy cikket a nehai linuxvilagban, hogy egy csavo azzal intezte el a C-ben irt cgi programok forkolasanak overheadjet, hogy ugyis az sql szerverre kell majd sokat varni...

--
"Pontosan ez a ti bajotok. Ez a kurva nagy csőlátás. [...]" (bviktor)

Queryk nagyja sajna dinamikus. Ami cachelheto, az mar cachelve, elogeneralva van. Masreszt meg van jónéhány szep, összetettebb query, ami pont, hogy nem nysql-ert kiált. (Foleg, ha lemennek az őszi fejlesztések, amiket MySQL-ben sztem meg sem lehet csinálni)

Szerk.: azert 2013-ban a CGI már nem túl menő, főleg, hogy sem egy program indítása, sem egy adatbázis-kapcsolat felépítése nem kis költség.

De egyébként, amivel lehetne még szépen novelni egy oldal sebességet, az az, ha pl. egy PHP-s program képes lenne appserverként üzemelni és be lehetne tölteni előre pl cikktörzset, ársorokat, stb. Most is meg lehetne ezt gányolni, csak az adatokat lenne halál szinkronban tartani.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

C-ben CGI, foleg 2013-ban, mikor 17 eves az fcgi? Jo vicc.

NoSQL meg nem csodaszer. Masreszt egy időben erre-arra volt memcached. Aztán kivágták a francba az egészet, mert nulla vagy olyan elenyésző volt, hogy azzal az erovel kihuzhattam pg-hol is es inkabb torekedtem a kod tisztán tartasan. Ram volt a gépben, PG is mar kvazi memcachekent mukodott.

---------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Nalunk is vannak ilyen oldalak, es sajnos nem lehet mindent cachelni, mert nagyon sok infonak masodpercre kesznek kell lennie. Raadasul csak olyan dolgot erdemes cachelni, amit 1-nel tobbszor is fel tudsz hasznalni a cache TTL soran.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

( veresdaniel | 2013. 09. 28., szo – 12:10 )

feladat függő. Kis, egyszerű oldalak lehetnek statikusak is akár. Akinek nincs nagyon specifikus igénye, viszont a tartalmat módosítgatni akarja, annak általában megfelel egy cms vagy cmf ( modx ;) ) . Célfeladatokra frameworköt (Laravel) használok.

( kodmen | 2013. 10. 04., p – 08:30 )

Erre szavaztam : Egy CMS-re (Drupal, Joomla stb.)

De még ezt is bejelöltem volna: Nem értek a webprogramozáshoz :-D

Kodmen
-------------------
"...a Linux filozófiája: Keresd a veszélyt. Hopp! Nem így van. Csináld magad! Ez az!" (Linus Torvalds)