Új hozzászólás Aktív témák
-
#11801
blacee
csendes tag
Sk8erPeter
#11799
blacee
csendes tag
válasz
Sk8erPeter
#11799
üzenetére
Sajnos semmi változás, különben már sűrűn köszöntem volna a segítséget!
El nem tudom képzelni mi kell még neki...blacee
-
Louro
őstag
Sziasztok,
nem vagyok teljesen kezdő, de azért segítségért fordulnék hozzátok.
Amiről szó van. Van egy űrlap. Bekérek adatokat, amit egy fájlban tárolok el.
Az űrlap első oszlopa egy sorszám - nem a bejegyzés sorszáma, szóval több sornak lehet ugyanaz a sorszáma.
A gond az az, hogy a kiíratáskor szeretnék egy olyat írni, hogy van - tegyük fel - 10 táblázat. A 10 táblázatba pedig szétszedni az adott sorszámmal kitöltött űrlapok adatait.Pl:
A fájl tartalma:
1;alma;torta;hétfő;
2;citrom;leves;csütörtök;
4;fahéj;tejberizs;vasárnap;
2;bors;pörkölt;kedd;
3;sajt;torta;hétfő;
2;krumpli;rakott krumpli;hétfő;======================================
A táblázatok nevei lennének a sorszámok (első adat) és az alattuk levő táblázatban jeleníteném meg a sorszám utáni 3 adatot soronként.
Amit csináltam: a fájlt egy változóba betettem - eddig alap -, után explode-dal szétszedtem egy tömbbe soronként.
De itt elakadtam, mert a foreach-et nem tudtam úgy megírni, hogy jó legyen. Próbáltam ciklussal, de nem ment. Nem tudom, hogy hogyan tudnám úgy szétszedni, hogy pl. a ciklus indexe a tömbelem első első karaktere legyen.Remélem sikerült érthetően megfogalmaznom. Adatbázissal még nem foglalkoztam, ezért nem abban "rögzítettem"/dolgoztam fel.
Köszönöm előre is a segítségetek.
[ Szerkesztve ]
Mess with the best / Die like the rest
-
#11803
Peter Kiss
senior tag
Louro
#11802
Kódoltam egy keveset, szerintem erre gondoltál: http://pastebin.com/mc8eJwfQ
(Hiba lehet benne [Notepad teszt nélkül].)
[ Szerkesztve ]
-
#11804
Louro
őstag
Peter Kiss
#11803
Louro
őstag
válasz
Peter Kiss
#11803
üzenetére
Uh, osztállyal.... - kezdő programozó vagyok - erre nem is gondoltam. Átnézem a kódot, hogy értelmezzem is.
Köszönöm a gyors megoldást.
Mess with the best / Die like the rest
-
#11805
Peter Kiss
senior tag
Louro
#11804
-
#11806
Sk8erPeter
nagyúr
blacee
#11801
Sk8erPeter
nagyúr
válasz
blacee
#11801
üzenetére
"Unknown package 'zoneinfo-europe'
Nem találja szegényke. Ő ugyanis a vargalex.uw.hu -ról rántja le a csomagokat, és azok közt nincs."
Ez azért furcsa, mert itt látom a listázásban a csomagot:zoneinfo-europe_2011n-1_ar71xx.ipk
Szóval nem nagyon értem, miért nem találja. Más package source-t (mirrort) beállítva (akár ezt) sem működik ennek telepítése?
==========
(#11805) Athlon64+ :
"Lehet ilyet osztály nélkül is?
"
Nyilván költői volt a kérdés, de mindent lehet procedurálisan is, semmi katasztrófa nem történik akkor sem (bár tudom, hogy szerinted aki nem csak és kizárólag OOP-ben kódol, az egy baromarcú), csak akkor elveszti az osztályok használatának rugalmasságát, a könnyebb kezelhetőséget, esetleg áttekinthetőbb kódot. De önmagában az, hogy OOP a kód, az nem garantálja az áttekinthetőséget, jó kódot, a gányolás elkerülését; ahogy ugyanígy az is igaz, hogy procedurálisan is lehet szép kódot írni.[ Szerkesztve ]
Sk8erPeter
-
#11807
Peter Kiss
senior tag
Sk8erPeter
#11806
válasz
Sk8erPeter
#11806
üzenetére
Procedurálisan nem lehet szép kódot írni, mert minden lóg a levegőben (illetve a globális hipertérben). Ilyen esetekben maximum egy-egy függvény feladatát lehet a minimálisra szorítani, de rendszer nem lesz abból se. PHP esetében pedig még az is kihullik, hogy típusellenőrzést lehessen jól láthatóan végezni (kikötöda paraméter típusát a metódusok paraméterlistájában).
Az OOP nem tudja garantálni a normális kódot, mivel nincs normálisan definiálva (lehet egyáltalán?), hogy mit is jelent az OOP (sokaknál kimerül a class-ok használatában, de ekkor van az, hogy class oriented lesz a design).És nem baromarcú, csak keveset tud.
-
#11808
cucka
addikt
Peter Kiss
#11807
cucka
addikt
válasz
Peter Kiss
#11807
üzenetére
Az eredeti hozzászólásban írt, 20 sorban megoldható feladathoz talán mégiscsak túlzás a te próbálkozásod, ahol hosszú oldalakon keresztül csak az oop kód zaja látható. A megoldásod elsősorban nem a feladatot oldja meg, hanem azt próbálja demonstrálni, hogy ismered az php-s oop kulcsszavak használatát - lényegében pont azt mutatja be, hogy hogyan ne írj jó oop-s kódot.
-
#11809
Sk8erPeter
nagyúr
Peter Kiss
#11807
Sk8erPeter
nagyúr
válasz
Peter Kiss
#11807
üzenetére
Alapvetően egyetértek, szerintem is adott esetben sokkal szebb és átláthatóbb lehet egy OOP-s kód, ha valaki tényleg jól tud kódolni.
Arra gondolok viszont, hogy pl. a Drupal magja sem teljesen OOP-s még, elsősorban örökség miatt - lásd PHP 4-es idők; nem egyszerű egy ilyen "rendszert" teljesen lecserélni; legalábbis a 7-esig, bár ott már sok minden OOP-sre lett alakítva, a 8-asnál meg még több dolgot ültettek át OOP-re, ezért van egy bizonyos keveredés egyelőre -, mégis alapvetően egész jól követhető a kód, amennyiben valaki már érti, miről is szól az egész, és itt is egy "rendszerről" beszélünk (azt írod, "rendszer nem lesz abból se", most erre reagálva mondom).
De én pl. a még jobb követhetőség miatt sokkal jobban örülnék, ha a modulfejlesztés is például osztályok leszármaztatásából, interfészek implementálásából és hasonlókból állna, mert számomra is jóval áttekinthetőbb lenne a kód. De van ilyen szinte full OOP-s modul: Views.
Igazad van abban, hogy így elég sok minden lóg a levegőben, ezt a hátrányt Drupalnál is érzem, a debuggolás is talán nehézkesebb emiatt. De a fejlesztők tudják, hogy van min javítani, ez is az irány. Itt és itt nálam sokkal jobban elmagyarázzák a miérteket.Ettől függetlenül szerintem picit túlzás, hogy csak az OOP-s kód a jó és mérvadó.
Szerk.:
cucka az előző hsz.-ben pedig elég tömören elmagyarázza azt is, amit én is éreztem a konkrét kérdés kapcsán, csak ő sokkal jobban megfogalmazta.[ Szerkesztve ]
Sk8erPeter
-
#11810
Sk8erPeter
nagyúr
Sk8erPeter
#11809
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#11809
üzenetére
Csak nem bírom magamban tartani: mindenki már érti és kívülről fújja, hogy te nagyon vágod ám a tervezési mintákat, és odáig vagy értük, de ez nem azt jelenti, hogy csak te tudsz emiatt jó kódot írni, és mindenki más, aki procedurálisan kódol (pl. korábbi kódot fejleszt tovább), az "keveset tud".
Hozzászoktam, hogy szereted erős túlzásokkal megspékelni a mondandódat, de azért ez már egy kicsit erős volt. Bár gondolom nem nagyon tudsz elképzelni olyan programozót, aki nem kódol OOP-ben, mégis nálad sokkal jobban tud programozni (szerk.: félre ne értsd, nem feltétlenül itt a topicban aktívan írókkal kell "versenyezned") - hiszen ahhoz kell némi szerénység, hogy az ember ilyesmit is el tudjon fogadni.[ Szerkesztve ]
Sk8erPeter
-
#11811
cucka
addikt
Sk8erPeter
#11809
cucka
addikt
válasz
Sk8erPeter
#11809
üzenetére
cucka az előző hsz.-ben pedig elég tömören elmagyarázza azt is, amit én is éreztem a konkrét kérdés kapcsán, csak ő sokkal jobban megfogalmazta.
Igen, az az elméleti okoskodás rész, ami akár elfogadható is lehet. (Nem az, ha valaki az informatikában megmondja a tutit, hogy csak és kizárólag egy módszer az elfogadható, na ő téved)
A másik oldal meg a kód, amiből lényegében a class oriented dizájn állatorvosi lova, kb. mint ha egy java programozó első php-s kódja lenne.A php egy szkripnyelv, ezt érdemes szem előtt tartani, hogy valóban php-ban írjuk a php kódot, nem pedig javaban.
-
#11812
Sk8erPeter
nagyúr
cucka
#11811
Sk8erPeter
nagyúr
"Nem az, ha valaki az informatikában megmondja a tutit, hogy csak és kizárólag egy módszer az elfogadható, na ő téved"
Na igen, én is ezt fejtegettem, hogy ne akarjuk itt megmondani a "one and only" módszereket.Azutánira: szintén egyetértek, ha valaki igazi OOP-s környezetet akar, akkor álljon át valamelyik webes Java-technológiára vagy például ASP.NET-re.
Persze ettől függetlenül nem megkérdőjelezhető az OOP létjogosultsága sem a PHP-ben.
Ahogy az is igaz, hogy amennyiben valaki az előbb említettekben IS programozik, annak az agya nyilván sokkal inkább rááll az OOP-s gondolkodásra, és nem valószínű, hogy engedni akar belőle (tehát ennek mentén fog kódolni PHP-ben is, amivel nincs baj). Viszont ez nem jelenti azt, hogy egy procedurális kód szar (sőt, nagyon jó is lehet, és nagyon nem arra utal, hogy az aszerint kódoló fejlesztő keveset tud [ettől a megjegyzéstől az agyam kinyílt]).[ Szerkesztve ]
Sk8erPeter
-
#11813
cucka
addikt
Sk8erPeter
#11812
cucka
addikt
válasz
Sk8erPeter
#11812
üzenetére
Azutánira: szintén egyetértek, ha valaki igazi OOP-s környezetet akar, akkor álljon át valamelyik webes Java-technológiára vagy például ASP.NET-re.
Van rengeteg "köztes" megoldás is, igazából manapság kevés olyan nyelvet használnak, ami ne lenne így vagy úgy objektumorientált - a php is ilyen.A probléma az idézett kódnál elsősorban az, hogy megpróbál túlságosan általános lenni, miközben ennek az égvilágon semmi értelme. Oop-vel könnyű olyan osztály hierarchiákat kialakítani, ahol minden komponens cserélhető, kiterjeszthető. A nehéz dolog előre látni, hogy a rengeteg lehetőség közül melyikre is lesz szükség valójában, és melyek azok, amelyek csak a program hosszát és a zajt növelik, hasznuk semmi. Például az említett kódban az összes oop rész gyengíti az alap algoritmus szemléletességét, miközben a feladathoz által nem megkövetelt komplexitást hoz be, megvalósítva azt az anti-patternt, ami "excessive accidental complexity" néven fut. (Van erre valami jó magyar szakkifejezés?
)annak az agya nyilván sokkal inkább rááll az OOP-s gondolkodásra, és nem valószínű, hogy engedni akar belőle
Szerintem a fejlesztő agya elsősorban a gondolkodásra kéne ráálljon. Mindenkinek javaslom, hogy hobbiból játszadozzon egy funkcionális nyelvvel (javaslatom a Clojure) - el fog bizonytalanítani, a szokásos pattern-ek nem működnek benne, pont ettől segít olyan sokat. Megtanít arra, hogy a feladatra és a program olvashatóságára figyelj, és ne foglalkozz semmilyen, valaki által kitalált és "one and only"-nak kikiáltott esztétikai iránymutatással.[ Szerkesztve ]
-
#11815
Peter Kiss
senior tag
cucka
#11808
Tudom, hogy a PHP script nyelv, de az is baj, hogy ebből nem bír kinőni, pedig egyre komolyabb dolgokra képes, illetve a Zend is próbál mindig jobban arra sarkallni, hogy objektumokkal dolgozzunk. Ezt annyira komolyan gondolom, hogy hobbiként fejlesztett rendszeremben a super global tömböket se kell használni.
Emellett nem is szeretek úgy gondolkodni, hogy van egy feladat, aztán azt a lehető legegyszerűbb, legrövidebb módon oldjuk meg, mert mi történik akkor, ha jön egy hasonló? Duplikálás. Nyilván a fenti kérdés egy kis dologra vonatkozott, de, ha esetleg van valami cifra folytatása, már megérhette, illetve abban az esetben, ha több helyen kell valamit használni (itt például a táblázatos történetet, a parser sántít).
Azt mondom, nem érdemes kicsiben gondolkodni.Mikor van hatalmas előnye annak, ha mindent a lehető legabsztraktabb módon írunk le? Akkor, ha tesztelni is akarjuk a kódunkat! Ha valaki fejlesztett már TDD módon úgy, hogy nem csak a covarege-et nézte, és gyártott a smoking test-eket, akkor tudhatja, hogy a jó tesztek kikényszerítik a fentebb látható kódstruktúrát, mert egyszerűen kell.
Mindenki elindulhat a saját útján, én megmutattam egyet, én hogyan csinálnám, akinek tetszik, használja, akinek nem, az ne (csak nehogy egyszer én legyen a projektvezetője
).---
#11809
"amennyiben valaki már érti" - ez a varázsgondolat
Ha jó a kód, ordít magáról, hogyan kell használni. Nyilván, a PHP-nak itt vannak korlátai, de azért nem olyan rossz a helyzet. A fenti kódra szerintem senki sem tudná azt mondani, hogy nem tudja használ (a parser itt is kivétel, annak még bőven alá kellene dolgozni).---
#11810
Nem vagyok programozó, szoftverfejlesztést szeretem, illetve az architect jellegű kérdésekkel, megoldásokkal foglalkozni.---
#11814
Egyik tervezési mintát sem kell vakon követni, hiszen nem előírások, csak megfigyelt jó fogások, vagy épp rosszak. Amit mindig be kell tartani: egy osztály/metódus egy problémát oldjon meg, mindig mondja el, mire van szüksége a működéséhez, és minden a lehető legabsztraktabb maradjon. Ha valaki ezeket szemmel tartja, nagy baj nem történhet. -
#11816
blacee
csendes tag
Sk8erPeter
#11806
blacee
csendes tag
válasz
Sk8erPeter
#11806
üzenetére
Az opkg update leszedi az összes csomagot becsomagolva, de abban nincs benne. A linkről amit küldtél külön letöltöttem a zoneinfo-europe_2011n-1_ar71xx.ipk-t és bemásoltam a /var/opkg-lists-be, újra se indítottam a lighttpd-t és láss csodát: M Ű K Ö D I K !
Nagyon köszönöm a segítséget!!!
BLacee
blacee
-
#11817
cucka
addikt
Peter Kiss
#11815
cucka
addikt
válasz
Peter Kiss
#11815
üzenetére
Tudom, hogy a PHP script nyelv, de az is baj, hogy ebből nem bír kinőni
A szkriptnyelveknek nagyon is van létjogosultsága és jövője, ne írd le őket.
A php baja leginkább az, hogy egy inkompetens fickó tervezte és mai napig a régi verziók rossz megoldásait nyögi a visszafele kompatibilitás miatt.a Zend is próbál mindig jobban arra sarkallni, hogy objektumokkal dolgozzunk
A Zend nem tudom, mire sarkall. Én úgy látom, hogy a php-ban egyre több a funkcionális nyelvekből átvett megoldás, ez pont nem az a tisztán oop-s irány.Ezt annyira komolyan gondolom, hogy hobbiként fejlesztett rendszeremben a super global tömböket se kell használni.
Úgy érzem, hogy te a lelked mélyén java-ban szeretnél fejleszteni (esetleg c#), a kérdés, hogy miért ragaszkodsz a php-hoz? Átveszed azt, amitől a java nem túl jó és kidobod azt, amitől meg a php igen. Hobbi szinten végül is mindegy, szerintem inkább érdemesebb minden eszközt arra használni, amire való.Emellett nem is szeretek úgy gondolkodni, hogy van egy feladat, aztán azt a lehető legegyszerűbb, legrövidebb módon oldjuk meg, mert mi történik akkor, ha jön egy hasonló?
Világos, viszont a túlzásba vitt általánosítás komoly veszély. Angolul "overgeneralization" néven fut ez az anti-pattern, amikor a lehető legáltalánosabb kódot szeretnéd írni anélkül, hogy tudnád, szükséges-e (kapcsolódik még ide a "premature optimization" nevű antipattern is).
Dolgoztam már ilyen, lehető legáltalánosabbra megcsinált php-s framework-el. A tapasztalat, hogy a korai általánosítás inkább ront a helyzeten, mint javít - nekünk folyamatos szopóroller volt, hogy ott volt a nagy, bonyolult keretrendszer, ami minden eshetőségre fel volt készítve, kivéve arra, amire épp szükség lett volna, tehát lehetett áttervezni/refaktorálni. A lehető legáltalánosabb kód írása papíron hangzik csak jól.Mikor van hatalmas előnye annak, ha mindent a lehető legabsztraktabb módon írunk le? Akkor, ha tesztelni is akarjuk a kódunkat
TDD-hez elég, ha moduláris a kódod, pl. globális függvényeket pont ugyanolyan jól fogsz tudni tesztelni. Persze, azért itt már előnyös az oop.
Smoke test-nek meg nincs igazán köze ahhoz, hogy oop-s vagy nem oop-s a kódod. -
#11818
cucka
addikt
Peter Kiss
#11815
cucka
addikt
-
#11819
Soak
veterán
Peter Kiss
#11815
Soak
veterán
válasz
Peter Kiss
#11815
üzenetére
(csak nehogy egyszer én legyen a projektvezetője )
Ha nem titok akkor hol dolgozol?
-
#11821
Peter Kiss
senior tag
cucka
#11817
Nem írtam le a szkriptnyelveket, de a PHP pont olyan, ami simán le tudja vetkőzni magáról a szkriptnyelvségét, és klasszul lehetne használni, csak épp az elterjedtsége ellenére is kevesen próbálkoznak kiaknázni minden lehetőségét.
Mit vett át funkcionális nyelvekből?
Java-ban nem szeretnék fejleszteni, .NET-ben lehetőségem van minden nap (@Soak: termelő vállalatnál kell ügyviteli és termeléstámogató szoftvereket fejleszteni, sajnos eddig szinte csak legacy [és szar] kódokat kellett támogatni). De akkor végül is azt mondod, hogy PHP-val hegesszen mindenki úgy, hogy csak az adott problémára koncentráljon, legyen kész, és rendben is van a dolog?
Overgeneralization-től még nagyon messze vagyunk, nyilván nem kell minden üzleti problémára egy mindent tudó solver-t írni, de azért arra oda kell figyelni, ne legyen semmi sem túlságosan összedrótozva. Premature optimization valóban veszélyes lehet, de igazából csak azt fenyegeti, aki rettentően unatkozik, és valamilyen oknál fogva előre látni véli a rossz teljesítményű pontokat.
Azért, mert dolgoznod kellett egy rosszul megírt keretrendszerrel, még nem jelenti azt, hogy mindenhol rémeket kell látni.
TDD-hez nem elég a modularitás, mert simán tudsz olyan kódot írni (OO vagy nem OO), amit egyszerűen nem bírsz tesztelni, vagy nagyon nagy mocskot kell csinálnod, ezzel szemben egy interface-ből stub-ot/mock-ot hegeszteni nem nagy mutatvány. (Smoke tesztnek tényleg nincs köze az OO/nem OO dologhoz (bármit lehet rosszul tesztelni), de nem is azért írtam.)
-
PazsitZ
addikt
Alapvetően abban egyetértek, egy házi 2 formos php kódot, lehet felesleges OOP-ben megírni.
Továbbá, ha már adott is egyegyszerűbb kód, felesleges egy csv felolvasást köré 5-10 osztályt felhúzni.Viszont, ha én kezdenék bele, akkor már fognék egy framework-öt, ami segítségével oldanám meg a dolgokat.
Alapvetően a PHP-s framework-ök is OOP irányba mennek, amit az én észrevételeim alapján a nyelv is egyre inkább támogat.
Abban van igazság, hogy ez script nyelv, de ettől még nem a register globals és levegőbe lógó függvények szempontjából kell használni szvsz.Amennyiben pedig elkezdesz egy OOP framework-kel dolgozni, akkor viszont igenis namespace és osztálystruktúrát kell használni, nem kavarni a dolgokat.
A TDD hasznos dolog, kellő rálátás esetén jobban ki is kényszeríti a szebb kódot, SRP-t, amiből már könnyen jön a panaszolt "overgeneralization".
(#11820) Soak:
Egyébként nem olyan könnyű eltalálni a balanszot.
Egyik oldalról ott van az a szabály, hogy csak a kért feature-t fejleszd, ne űrhajót.
Másik részről viszont rá lehet/kell érezni, mi az, ami a következő iterációban biztos be lesz rendelve. Ebben az esetben pedig nem árt, ha kicsit előre gondolkozva tervezel, kellő mértékben absztrakt a kódod, hogy ne kelljen szétdúrni és gyors-hatékony lehess.[ Szerkesztve ]
- http://pazsitz.hu -
-
Soak
veterán
válasz
PazsitZ
#11822
üzenetére
Egyértelmű, nem is azt mondtam, hogy szar kódot kell írni, de amikor nem csak tul kell bonyolitani egy példa kódot hanem több százezer (millió) sort kell lekódolni akkor kicsit átértékelődik, hogy mit hogyan merre , mivel emberek írják a kódot, ezért az emberek számára kell azt logikussá tenni és könnyen átláthatóvá.
Nyilván ezt szinesíti amikor csapatban kell dolgozni és a folyamatos monitorozása annak, hogy ki-mit commitol a közösbe, mert amikor 50-60 ember dolgozik aktívan valamin akkor ha egy hibát kell javítani, az első 1óra azzal megy el, hogy feltérképezed a pontos folyamatot (és ez egy erősen OOP-s kód, viszont a projekthez mérten a lehető legátláthatóbban tartva és nagyon jól doksizva ) , na most ha itt minden sorban van két interface meg osztály akkor egy olyan hiba (vagy fejlesztés) ami amúgy egy logikus kódnál 3 óra, itt 2 nap.
Szvsz (ha csak szigorúan azt számoljuk ami a logikát végzi ) akkor 3 fő réteggel meg lehet oldani. controller-üzletilogika-adatbázis réteg. Itt az adatbázis müveletek jelentik az elemi müveleteket amik a konkrét adatot szolgáltatják, az üzleti logika ezt tetszés szerint kombinálja (a lehető legegyszerübben) , a controller pedig gondolkozik.
Innen már késöbb is el lehet indulni mondjuk egy bonyolultabb api megépítéséhez , vagy egy config réteget is betoldhat nagyon egyszerűen (ha indulásnál még nem volt).
Mérlegelni kell, hogy mire van nagyobb esély : Jelentősen többet kódolok, hogy majd egyszer valamit könnyen betoldok, de ugysem gondoltam felére sem ami lehet, tehát sokkal nem vagyok beljebb, vagy az egyértelmű és általános modulokat megépítem amik közé egy kicsit több kódolással, de ugyanolyan logikusan beillesztek bármit.
Szerk: Ahelyett, hogy a kód írást az vezetné, hogy mennyire jól tesztelhető, sokkal egyszerűbb egy komplett tesztkörnyezetet fenntartani (2 lépcsőbe- saját, aztán közös) ahol mindent rendesen ki tud tesztelni a megfelelő ember (hiba/feature bejelentője és a teszter vagy kinek mit teszik) egy jó dokumentáció mentén és jó rendszerismerettel .
[ Szerkesztve ]
-
Soak
veterán
Jah és amit még akartam írni , olyan szerenécs (?!) helyzetben vagyok, hogy egy 10éves legacy kódon és egy 1 éves (hasonlóan felépített kódot mint alább írtam, természtesen sok ezer munkaórával töketesítve ) kódon dolgozhatok és mind a kettővel meg lehet mindent oldani.
Persze akármilyen mozzanat a régiben komplett részlegek refactorálásához kéne hogy vezessen, de ez nem von le abból, hogy tökéletesen (és viszonylag elfogadható erőforrásigénnyel) fut.
-
#11825
Peter Kiss
senior tag
Számomra itt a beszélgetés folyamán kicsit úgy tűnik, mintha két dologról lenne szó: az egyik, hogy megoldunk egy problémát, azt hogyan programozzuk le, a másik, hogy előbb megépítjük a környezetet, és azt hogyan programozzuk le. Nem tudom, lehet, hogy nekem tűnik így. Mindegy, tegyük túl magunkat a felhozott kódolási anti-pattern-eken:
@Soak: Abban az esetben, ha van egy üzleti problémánk, akkor semmiféle képpen sem fogunk attól többet fejleszteni, mint amennyi szükséges. Vegyük azt, hogy egy teljesen új dologról van szó, nem kell régi vacakkal foglalkoznunk, és emellett van egy keretrendszer (ez lehet bármi, .NET, Zend Framework, mindegy), amiben dolgozunk. Tételezzük fel, hogy tiszta a megvalósítandó üzleti logika, gyakorlatilag csak fejlesztenünk kell. Hogyan érdemes ezt elkezdeni?
Írunk teszteket, amelyek lefedik nagyvonalakban, amit szeretnénk kivitelezni, ilyen fázisban még a teszt is ocsmány lesz, mert csak körbelőjük, mit is szeretnénk. Ha ez megvan, megírjuk az első kódot, teszt, kódírás/refaktor/újabb teszt, innen már tudjuk, TDD.
Ha így fejlesztünk, akkor észrevetjük, hogy az elején nagyon sokat kódolunk (leginkább a tesztek megírása miatt, nem az interface-ekre (vagy akár a mock-okra, stub-okra) gondolok, mert az relatíve kevés időt vesz igénybe), ellenben automatán tudunk mindent tesztelni (UI-t nehézkes ilyen szempontból, törekedni kell arra, hogy ott a lehető legkevesebb hiba fordulhasson elő). Mikor jó egy unit teszt?
Ha azt és csakis azt teszteli, amit kell, gyorsan lefut, és egyértelmű a leírása. Ahhoz, hogy a teszt ilyen legyen az kell, hogy maga a tesztelendő kód is felvegye ezt a jelleget, normálisan megírt OO kód nélkül ez lehetetlen.
Persze, a unit tesztek önmagukban kevesek, hiszen attól, hogy egy-egy rész jól működik, a big-picture még lehet, hogy sz.rt se ér, ehhez integrity test-ek kellenek.
Mit látunk ezen a ponton?Összevetve egy nem TDD-s csapattal, sokkal több időt töltöttünk mindenféle kód (production + ami a teszthez kell [és a világos megoldáshoz!]) megírásával, viszont sosem kell amiatt aggódnunk, hogy nagy hibát vétenénk, ha kalapálunk valamit, segítenek a tesztek. Hibát keresni is sokkal gyorsabb lesz, hiszen rengeteg dolgot fejlesztési időben ki tudunk szűrni, illetve a kiadott verzióban is kevesebb lesz az utólagos hibák száma.
Azt már említeni se merem, hogy léteznek olyan eszközök, amelyek kódolás alatt automatán futtatják a teszteket, így mindig up-to-date lehetsz (PHP-hoz nem tudom, van-e ilyen).
-
PazsitZ
addikt
ha itt minden sorban van két interface meg osztály akkor egy olyan hiba (vagy fejlesztés) ami amúgy egy logikus kódnál 3 óra, itt 2 nap
Megfelelő tesztekkel, rögtön ki kell, hogy bukjon a hiba helye. Ilyen szempontból pont jól beazonosíthatóan, mivel a felelősségi körök szét vannak osztva. Az interface pedig pont egyfajta contract, ami alapján az együttműködést lehet biztosítani.
A szar, logikátlan kódtól persze az OOP sem véd meg egyáltalán, de ezt senki nem állította.százezer (millió) sor
Olyan pedig pont nem létezik, hogy egy teljes rendszert részletesen, véglegesen lespecifikáljanak neked.
Tehát az esetek többségében, úgyis fejlesztési iterációk vannak, ezáltal pedig úgyis vagy aránylag rugalmasan oldod meg a dolgokat, vagy refactorálhatsz.az emberek számára kell azt logikussá tenni és könnyen átláthatóvá.
Itt nem tudom mire gondolsz, mi a nem logikus kód számodra.
Jelentősen többet kódolok
Én pont nem azt írtam, hogy jelentősebben többet kódolj.
A nem jól tesztelhető kódot, hogy tudja rendesen kitesztelni a megfelelő ember?
Én itt egy kis ellentmondást érzek. Avagy a kitesztelés nem az én gondom, oldja meg más, ahogy akarja?![;]](//cdn.rios.hu/dl/s/v1.gif)
Egyébként a rosszul tesztelhető kód a legtöbb esetben egy jelzés lehet a kódra nézve.[ Szerkesztve ]
- http://pazsitz.hu -
-
#11827
DerStauner
senior tag
DerStauner
senior tag
sziasztok!
van egy tábla egy honlapon, amibe az adatokat adatbázisból olvassa be a honlap (php-vel).
igaz az, hogy az ilyen táblának excel-be való exportálása php-val nehézkes? -
#11830
Peter Kiss
senior tag
DerStauner
#11827
válasz
DerStauner
#11827
üzenetére
Vannak rá kész lib-ek, szóval nem az. Google a barátod.
-
dodopek
addikt
Sziasztok!
Tudom, hogy nem kifejezetten php probléma, és volt is már itt vita, hogy a szerver konfig, és hasonló problémák ideférnek-e, de szerintem ha valahol, akkor itt biztos kaphatok választ,és szerintem igenis ideférnek az ilyen problémák.Xoo.hu ingyenes tárhelyére próbáltam feltolni phpbb fórumot. Már a file-okat sem sikerült feltelepíteni, mert a .htacces file-oknál (mindegyiknél) átviteli hibát jelzett. Minden más kiterjesztés gond nélkül felment, de ezt valamiért nem akarja megenni. TC-rel ftp-zek.
Van valami ötletetek, hogy mi lehet a gond?
Én barmolok el valamit?
Köszi!Közben válaszolt az ottani rendszergazda, nem fog menni.
"PhpBB és egyéb CMS rendszerek nem fognak működni az ingyenes tárhelyen. Arra fizetős tárhelyünket érdemes igénybevenni ahol komoly webpanellel , statisztikával, jelszavazott mappákkal és egyéb extrákkal lehet menedszelni a tárhelyet, mindamellett CMS-ek is gond nélkül futnak"[ Szerkesztve ]
-
#11832
cucka
addikt
Peter Kiss
#11821
cucka
addikt
válasz
Peter Kiss
#11821
üzenetére
Nem írtam le a szkriptnyelveket, de a PHP pont olyan, ami simán le tudja vetkőzni magáról a szkriptnyelvségét
Nem kell levetkőzze magáról. A szkriptnyelv nem alacsonyabb rendű, mint a hagyományos, típusos, fordított nyelvek, hanem más.
Az egyik kedvenc tech blogomon pont ma jött ki egy bejegyzés, amivel maximálisan egyet tudok érteni, lásd itt . (Érdemes a többi bejegyzést is olvasgatni, nagyon jók)Mit vett át funkcionális nyelvekből?
Utánanézve azért túl sokat nem. Vannak lambdák, van closure, már csak valamiféle "list comprehension" kéne (tervezik), továbbá ott vannak régről a map, filter, reduce, stb. eszközök. Persze az új dolgok szintaxisa igazi kendácsolás, de hát az egész php nyelv ilyen, meg van kötve a kezük a sok évvel ezelőtti rossz döntések miatt.Java-ban nem szeretnék fejleszteni, .NET-ben lehetőségem van minden nap
Na, hát csak kibújt a szög a zsákból. Igen, a .net (vagy a java, mindegy) tisztán oop-s szemléletet kényszerít rád, ez van, amikor előnyös és van, amikor annyira nem előnyös.
Mellesleg nagy feladatokat mostanában mindenhol oop elvek mentén fejlesztenek, igen, még szkriptnyelvekben is. Ami a szkriptnyelvek előnye itt, hogy a java/c# jellegzetességének számító boilerplate kódok hiányoznak.Overgeneralization-től még nagyon messze vagyunk, nyilván nem kell minden üzleti problémára egy mindent tudó solver-t írni, de azért arra oda kell figyelni, ne legyen semmi sem túlságosan összedrótozva.
Azokat a komponenseket, amelyek megállnak a saját lábukon és újra felhasználhatóak, azokat lib-eknek hívjuk. Egy egyedi szoftver egyedi megoldásaiból sosem lesz lib, sosem fogod újra felhasználni őket. Szóval akkor miért kéne magad azzal sz*patni, hogy úgy írd meg a szoftvert, mint ha egy csomó részét újra fel szeretnéd használni?
Nem azt mondom, hogy írjunk direkt szar kódot, hanem hogy a fejlesztés során megcsinált általánosítások nagy része teljesen fölösleges.Azért, mert dolgoznod kellett egy rosszul megírt keretrendszerrel, még nem jelenti azt, hogy mindenhol rémeket kell látni.
A keretrendszer jól volt megírva és elméletileg k*rvajó kellett volna legyen, a probléma, hogy a valós igények nem pont olyanok, mint amit elméletileg előre el tudsz képzelni.TDD-hez nem elég a modularitás, mert simán tudsz olyan kódot írni (OO vagy nem OO), amit egyszerűen nem bírsz tesztelniű
Miért, oop-val nem tudsz nehezen tesztelhető kódot írni, ha nagyon akarsz?[ Szerkesztve ]
-
#11833
Peter Kiss
senior tag
cucka
#11832
Szkriptnyelvség: behányunk valamit valahová és valami kijön, ezt lehet könnyen levetkőzni.
Lambdák vannak típusos nyelvekben is, .NET-be egészen durván jelen vannak.
Ezt az általánosítást ne ferdítsd már el a hülyeség irányába.
Egyedi szoftvert is kell általánosítani, mert különben túl bonyolult lesz a megvalósítása, ez kimerülhet pl. egy IStatus interface egy metódusában is, de jelen van, mert kell.Nálam az a keretrendszer, amivel nem lehet dolgozni, szarnak minősül. A "jól van megírva" dolognak két oldala van, maga a keret kódja penge, vagy az, ami kívülről lehet látni, mivel keretrendszert nem azalapján ítélünk meg, mi van benne, így a külsőleg látható elemekből kell döntést hoznunk arról, jó-e vagy sem.
Utolsó bekezdéshez annyit, hogy idézted a mondandó felét, illetve a kérdésedre még ebben a kis részben is megvan a válasz.
-
#11834
Swifty
csendes tag
Peter Kiss
#11833
Swifty
csendes tag
válasz
Peter Kiss
#11833
üzenetére
Nem akarok beleszólni, de:
- Pár oldal óta ez a topic nem a PHP-ről szól, hanem hogy milyen fika, milyen szar az egész...
- Azt olvasom, hogy te milyen nagy programozó vagy, és aki nem úgy készíti el a programjait, mint te, aki már a magzatvízzel is kódokat szívtál magadba, az mekkora szar...
- Aki mást mond mint te, az hülyeséget beszél, belehány valamit valahova, egy szóval fikagép...Na ezek után nem értem mi a f*szt keresel itt... Merthogy nem segítettél senkinek "PHP kérdések"-ben, azt bárki láthatja...
Még offtopic-ként sem jelölöd meg a kötözködéseid...
-
#11836
Sk8erPeter
nagyúr
mobal
#11835
Sk8erPeter
nagyúr
Nekem aztán nem tisztem megvédeni Athlont, mert az eddigi kommunikációnk egymással nem volt túl sikeres, meg sokszor küldte már rám a modikat, és azzal is egyetértek, hogy általában túlságosan köti az ebet a karóhoz, és a saját elveit tekinti mindenhatónak, de ettől függetlenül szakmai szempontból érdekes olvasni a fenti vitákat, az ő hozzászólásaival együtt is, amikhez cucka és fordfairlane meg Soak és még esetleg mások is hozzászólnak.
A PHP-fejlesztés rejtelmeiről és mikéntjéről esik szó, összehasonlítva egyéb nyelvekkel is a lehetőségeket, nem tudom, miért kell leállítani egy ilyen szakmai vitát... Úgy érzem, ebben az esetben a moderálás nem jogos (nem anyázás folyik!), mert így csak agyoncsaptok egy végre érdekes eszmecserét, amiben nem az a téma, hogy hogyan kell validálni egy nyomorék formot. Szerintem a negatív kritika is része egy szakmának.Szerk.: OFF.
Szerk. 2.: mobal, most látom, hogy ez te vagy, moderátor lettél, mik nem történnek (meg az avatarod is lecserélődött, ezért nem ismertelek fel)...[ Szerkesztve ]
Sk8erPeter
-
#11837
j0k3r!
senior tag
Sk8erPeter
#11836
j0k3r!
senior tag
válasz
Sk8erPeter
#11836
üzenetére
teljesen egyetertek veled, habar en csak csendes szemlelokent kovettem az elmult napok hozzaszolasait. jo volt vegre valami "advanced" temarol olvasni, nem mindig csak a sablon (~ 2 perc google) kerdesekrol.
some men just wanna watch the world burn...
-
#11838
mobal
MODERÁTOR
Sk8erPeter
#11836
válasz
Sk8erPeter
#11836
üzenetére
Félreértés ne essék a hozzászólásom off, nem hivatalos!
Következő a problémám: olyan linket szeretnék készíteni, amire kattintva egy fájl le tudok "tölteni". Lényegében egy galériához "download" linkeket. Olvastam, hogy cUrl-el könnyen megoldható, viszont ennek a hiányában milyen módszert javasolnátok?
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
#11839
Sk8erPeter
nagyúr
mobal
#11838
Sk8erPeter
nagyúr
Ennek örülök, bár ha egy modi mondja azt, hogy na kuss, akkor általában azzal agyon is van csapva a szakmai beszélgetés. Most már komoly felelősség terhel minden szavadért.
Bocs, de "force a download in php" kulcsszavakkal rákeresve, meg a PHP header() manualját megnézve is elég sok olvasmányt találni a témában...
Mintha épp az előbb lett volna szó a 2 perc Google-ről.
De a felvetést nem is értem, miért kell általad fejlesztett oldalhoz cURL? Vagy csak félreértettem a kérdésedet?(#11837) j0k3r! :
jaja, pontosan. Elég régóta érdektelenek a topicbeli kérdések is, most legalább valami érdekesről van (volt) szó.[ Szerkesztve ]
Sk8erPeter
-
#11840
Speeedfire
nagyúr
mobal
#11838
Speeedfire
nagyúr
Sima egyszerű header manipulálást.
<?php
$file = str_replace('../','',$_GET['file']);
header ("Content-type: octet/stream");
header ("Content-disposition: attachment; filename=".$file.";");
header("Content-Length: ".filesize($file));
readfile($file);
exit;
?>Még mielőtt Athlon beszóna' ez csak egy alap példa!
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
cucka
addikt
Nem kell hozzá curl. Lényegében a galéria letöltős linked egy php oldalra fog mutatni (mondjuk oldaladneve/download_gallery.php?gallery_id=5 ). A php szkript összeszedi a galéria file-jait, bezippeli és elküldi a kliensnek. A küldés lényegében annyit jelent, hogy beállítod a megfelelő header-eket (elsősorban content-type), majd egyszerűen kiírod a zip file tartalmát a standard kimenetre (vagy csinálhatod fpassthru-val is, gyorsabb).
A kényes kérdés itt a zip-elés. Több lehetőséged van:
- A php zip eszközeivel menet közben állítod elő a zip filet. Ezzel az a baj, hogy hamar ki fog futni a memóriából a php.
- A php meghív egy shell script-et, ami elvégzi a zip-elést (parancssoros zip-el), a zip filet lerakja a temp-be. Te onnan fpassthru-val kiköpöd a standard kimenetre, majd törlöd a filet.
- Minden galéria módosításnál elkészíted a zip filet, így bármelyik galériát is szeretné letölteni a júzer, csak átdobod neki a meglévő filet. Ez jó, ha ritkán változik a galéria, viszont gyakran töltik le egyben. A zip file elkészítésére a fenti 2 pont érvényes.(#11840) Speeedfire
Ez jó, csak az alap probléma, hogy nem 1 file-ról van szó, hanem többről (galéria). Ezért a zip-elés.mod: továbbá érdemes tudni, hogy a böngészők igyekeznek intelligensen kezelni az érkező file-okat. Ezért van az, hogy egy zip filet automatikusan felajánl letöltésre anélkül, hogy varázsolni kéne a http header-ekkel. Nyilván, egy jpeg file-nál rá kell erőltetni ugyanezt a viselkedést a megfelelő header-ek segítségével.
[ Szerkesztve ]
-
#11842
Peter Kiss
senior tag
Swifty
#11834
válasz
Swifty
#11834
üzenetére
Amennyiben ez PHP topik, akkor nem szeretnék látni semmit sem, ami MySQL vagy Apache (és hasonló jellegű) témával foglalkozik, köszi mindenkinek!
Nem tudom, mennyire vagy benne a témában, de egy idő óta (segítek: utoljára arról volt szó, mennyire kell ráállni PHP-ban az iobjektum orientáltságra, hogyan építsük fel a kódjainkat, hogy ne szívjunk nagyot véletlenül se, ilyesmi) a tiéd volt az első off topik hozzászólás, amiben senkinek sem segítettél, illetve nem a PHP-tól beszéltél. Csak azért, hogy lekiabálj valakit (főleg ilyen alapon), nem kell írni.Látod, most bekattintom az off topikot.
-
#11843
mobal
MODERÁTOR
Sk8erPeter
#11839
válasz
Sk8erPeter
#11839
üzenetére
"Nem kell rögtön megijedni vagy hogyan fogalmazzak. Csak és szigorúan a saját véleményem volt. Természetesen a szakmai vita részét fontosnak tartom én is, de sok hozzászólásból nekem nem "csak" ez jött le, de lehet az én hibám!"
Pontosítok. Megpróbálom úgy leírni, legegyszerűbben, hogy érthető legyen - Google volt ezeket megtaláltam csak nem tudom jó-e nekem, még nem próbáltam ki. Szóval úgy szeretném megoldani - és most egy buta példa - amit Chrome esetében tapasztaltam, hogy rákattintok és rögtön a képet tölti le, vagy adott esetben új tabot nyit, elindítja a letöltést majd bezárja (szempillantás alatt). Remélem így más érthetőbb!
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
#11845
cucka
addikt
Speeedfire
#11844
cucka
addikt
válasz
Speeedfire
#11844
üzenetére
Így olvasva a köv. hozzászólásokat, nekem úgy tűnik, hogy kettőnk közül én értettem félre, és tényleg 1 fileról van szó.
-
Inv1sus
addikt
$pagecontent = preg_replace( array("#( width=\")(.*)(\")#e", "#( height=\")(.*)(\")#e"), array("", ""), $pagecontent);
Ezzel a sorral azt szerettem volna elérni, hogy egy szövegből, ami egy html kód, kiszedje a width és height attribútumokat.
Kérdésem az lenne (úgy tűnik, hogy sikerült ezt megcsinálni), lehet-e valamit szépíteni rajta, illetve valamilyen hibalehetőséget rejt-e magában?[ Szerkesztve ]
*** WEBDESIGN, GRAFIKUS DESIGN, FRONT-END PROGRAMOZÁS ***
-
#11847
Sk8erPeter
nagyúr
Inv1sus
#11846
Sk8erPeter
nagyúr
válasz
Inv1sus
#11846
üzenetére
Igen, elég sok hibalehetőséget rejt magában.
Pl. azt, hogy konkrétan kiszedi az összes attribútumot pl. egy ilyen esetben:<img width="123" src="asdasd.jpg" height="123" title="blabla" alt="akármi" style="border:1px solid red;" />
amit készít belőle:
<img />Asszem ez neked nem lesz túl jó.
itt kipróbálhatod:
http://preg_replace.onlinephpfunctions.com/Hint: (.*) - ez így nem igazán szűkíti le a dolgokat.
Szerk.: áááá, inkább mutatok rosszabbat, hogy még inkább elrettentsen.
<div title="valami"><img width="123" src="asdasd.jpg" height="123" title="blabla" alt="akármi" style="border:1px solid red;" /><div style="color:red;" title="asd">ezmegaz</div><p style="color:red;" title="itt is">namégegy</p>
</div>ebből csinál egy ilyet:
<div title="valami"><img>namégegy</p> </div>
elég brutálisan szétkúrja.[ Szerkesztve ]
Sk8erPeter
-
#11848
Inv1sus
addikt
Sk8erPeter
#11847
Inv1sus
addikt
válasz
Sk8erPeter
#11847
üzenetére
Nálam csak a width és height tagokat szedte ki.
Ebből:
<img style="float: left;" alt="Minta 1" src="../user_uploads/images/oldalak/kezdolap/pic1.jpg" height="118" width="118" />[ Szerkesztve ]
*** WEBDESIGN, GRAFIKUS DESIGN, FRONT-END PROGRAMOZÁS ***
-
#11849
Sk8erPeter
nagyúr
Inv1sus
#11848
Sk8erPeter
nagyúr
válasz
Inv1sus
#11848
üzenetére
Igen, mivel te a stringed legvégére adtad meg a width és height attribútumokat...
Te arra számítasz, hogy mindig így lesz? És arra számítasz, hogy csak és kizárólag <img> tagek lesznek a stringedben? (utóbbi még talán előfordulhat)Próbáld már meg, amit mutattam.
2 próba:
De tessék, itt van, amit mutattál, csak úgy, hogy az elejére teszem a height és width attribútumokat:
<img height="118" width="118" style="float: left;" alt="Minta 1" src="../user_uploads/images/oldalak/kezdolap/pic1.jpg" />
Screenshot:
Most már hiszel nekem?
[ Szerkesztve ]
Sk8erPeter
-
#11850
Swifty
csendes tag
Peter Kiss
#11842
Swifty
csendes tag
válasz
Peter Kiss
#11842
üzenetére
Igen, ez PHP topik... De a PHP foglalkozik MySQL-el és kötődik hozzá az Apache...
Ha nem szeretnéd ezt olvasni, akkor javaslom, hagyd ki a kérdést.
Igazad van, én is kihagyhatnám, hogy Neked válaszoljak...Benne vagyok én is a témában (már ha itt arra célzol, hogy programozok-e PHP-ben vagy más nyelven, esetleg ismerem-e az OOP-t).
Természetesen enyém volt az "első" offtopic, de ha jól emlékszem, akkor meg is jelöltem, hiszen arra próbáltalak rávezetni, hogy nem csak beszélni kellene a howto-król, hanem meg is kellene mutatni hogy mit hogyan.... Javítom magam: inkább szerintem pont ezt kellene "erőltetni", és nem az elméleteket gyártani...
Személyes véleményem, hogy szép az OOP, de vannak olyan esetek, amelyikben teljesen "ágyúval a verébre" effektust generál, ha mindent objektumban kell legenerálni...
Már ne is haragudj, (és elnézésedet kell kérnem, ha úgy vetted) de nem kiabáltalak le... Nem annak szántam, hanem inkább annak, hogy légyszi gondold át, hogy mit írsz... Elhiszem, hogy milyen nagy dolgokat írtál már, illetve hogy milyen szuper tematikákat ismersz, de azt gondolom, hogy ez nem segít mindenkinek...
Itt problémák merülnek fel, amikre megoldásokat kell(ene) találni, akár a google segítségével, akár azzal, hogy elmondjuk, mennyire szarul képzeli el a delikvens az adott problémát...
Köszönöm, hogy elolvastad a válaszom és hogy bekattintottad az offtopic-ot !!!
Ez is elég gagyi, mert pl. a parser-nek erős függése van, azt még fel kellene oldani, hogy ne legyen CSV fájlhoz kötve.
)
).
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
- Adatmentés - HDD - SSD - Flash
- Milyen NAS-t vegyek?
- A Watch7-tel debütálhat a Samsung vércukormérője
- Kerékpárosok, bringások ide!
- Magga: PLEX: multimédia az egész lakásban
- Házimozi belépő szinten
- PlayStation 5
- LG 34GS95QE-B: OLED paneles, ívelt gamer monitor
- Teljes verziós, ingyenes mobil játékok és alkalmazások
- Bambu Lab X1/X1C, P1P-P1S és A1 mini tulajok
- További aktív témák...
- Philips 58PUS8545/12 1 ÉV GARANCIA Játék üzemmód
- Tyű-ha! HP EliteBook 850 G7 Fémházas Szuper Strapabíró Laptop 15,6" -65% i7-10610U 32/512 FHD HUN
- Bomba ár! HP EliteBook 840 G5 - i5-8G I 8GB I 128GB SSD I 14" FHD I HDMI I Cam I W10 I Gari!
- The Last of Us Part I Ps5
- Bomba ár! HP EliteBook 830 G6 - i7-8G I 8GB I 256GB SSD I 13,3" FHD I HDMI I Cam I W11 I Gari!