Hirdetés
- Évente csak egyszer látod! 11 11 11 11 11
- Szárítógép szösszenet (hogy Te ne járj pórul)
- "A homoszexualitás természetellenes" 😠
- Szólánc.
- Mindent a StreamSharkról!
- Asszociációs játék. :)
- Digitális Állampolgárság Program
- Airfryer XL XXL forrólevegős sütő gyakorlati tanácsok, ötletek, receptek
- Nagy "hülyétkapokazapróktól" topik
- GPU-k mindörökké - a kezdetek?
Új hozzászólás Aktív témák
-
martonx
veterán
válasz
cidalain
#4866
üzenetére
Azért egy Netbeans konfig nem 15 perc. ??? Bevallom, kizárólag PHP-zásra használom, de az utóbbi évek újratelepítéseiből nem emlékszek olyanra, hogy bármikor is érdemben konfigurálni kellett volna a Netbeans-emet.
Most is 7.3-as van fent, a konfigját egyszer láttam, amikor átállítottam sötétre a megjelenését. Pedig megy vele XDebug is.Én kérek elnézést!
-
martonx
veterán
Na most egy oldal vagy tök statikus, de akkor nincs mit adminisztrálni rajta távolról, vagy dinamikus és akkor van keresni valója az admin felületnek.
Azaz ezeket első körben vagy át kell alakítanod dinamikussá, vagy meg kell oldanod, hogy az általad írt admin felület át tudjon nyúlni más szerverekre, más tárhelyekre és ott távolról mondjuk FTP-vel le tudja hozni a .html-eket, és azokat megjeleníteni magadnál, majd menteni, ésvissza FTP-zni a végeredményt.
Szerintem ez így elég macerásan hangzik.Én kérek elnézést!
-
martonx
veterán
válasz
cidalain
#4882
üzenetére
Szerintem te érted félre. Van egy oldalad az X, meg egy az Y, és végül egy harmadik a Z tárhelyén.
Namost ha ezekhez akarsz egy közös admin felületet, akkor mégis hogyan fogsz belenyúlni bármelyik file-ba is a W tárhelyről? A MySql-eket sem fogod tudni távolról elérni. szóval én alapból bukónak érzem a feladatot, maga az elképzelés is elég extrém, bár mondom informatikáról beszélünk, és ha nehezen is, de minden megvalósítható.Bár van egy ötletem. Ha emberünk csinál egy jó kis web api-t, akkor onnan a sok statikus oldalakra JS-t kirakva, könnyen megoldható, hogy áthúzzunk némi dinamikus tartalmat, mondjuk híreket.
Én kérek elnézést!
-
martonx
veterán
válasz
cidalain
#4891
üzenetére
Sk8erPeter arra értette, hogy van egy vélekedés, miszerint a komoly programozó kerüli a CMS használatát. Van létjogosultsága a CMS-eknek, én személy szerint mondjuk azt nem szeretem, mikor lassan programozni már senki nem is akar, csak összekattintgat valamit mindeféle háttér tudás nélkül, aztán meg jön gyökérségeket kérdezni, meg észt osztani, mert ő már igazi programozó.
Én kérek elnézést!
-
martonx
veterán
Azért manapság a mobilhoz külön css, meg js-el ellenőrzés, és css váltogatás elég fapados megoldások.
Erre valóak a mediaquery-k a css-ben. Egy bizonyos felbontáshoz tudd igazítani a css tulajdonságokat.
Ha pedig valóban külön js-ekre van szükség az oldalon a mobil kezeléshez (mondjuk jquery ui, helyett jquery mobile), ezt úgyis szerver oldalon érdemes kezelni, nem kliens oldalon.Én kérek elnézést!
-
martonx
veterán
"Kis cégnél, Budapesten, ilyenekért jellemzően nettó 1000-es órabért kap a melós."
Lényegtelen, hogy a melós milyen nettó órabért kap, ha a cég 5K alatti + áfa órabérrel nem fogja elvállalni. Abba gondolj azért bele, hogy a cégnek a számla után áfát, meg mindenféle adót, végül a melósnak bruttó fizetést, plusz a bruttó fizetésen felül mindenféle egyéb adót + járulékot kell fizetnie, és akkor még vannak rezsiköltségei is a cégnek.Én kérek elnézést!
-
martonx
veterán
Igen én is erre próbáltam rávilágítani. Illetve aki ezt főállásként űzi, annak csomó egyéb költsége tud lenni, plusz azt is bekalkulálja, hogy ha 1-2 hónapig nem jön össze annyi meló, akkor se haljon éhen, szóval ahogy mondtam a picit is komolyan vehető (és hivatalos, számlaképes) webfejlesztők nettó 4K / óra + áfa alatt nem dolgoznak.
Aztán persze tudok olyat, aki szaré-hugyé dolgozik főállásban, mondjuk a munkája olyan is![;]](//cdn.rios.hu/dl/s/v1.gif)
Másrészt van is megrendelése bőven, mert még mindig többségben vannak azok, akiknek fontosabb, hogy szinte ingyen legyen, mint az, hogy valóban jó is legyen a végeredmény.Én kérek elnézést!
-
martonx
veterán
válasz
TomKiss
#5026
üzenetére
Fel kell készítened az oldalt reszponzív dizájnnal a létező legszélesebb felhasználói körre.
Esetedben persze lehet, hogy elég egy sima meta viewport-os bejegyzés is a html-be, és ettől esetleg máris megjavul a mobilos böngészőben mutatott érdekes viselkedés.Én kérek elnézést!
-
martonx
veterán
válasz
Chrystall
#5069
üzenetére
IE10 már egészen szabványos, így ez a nem szabványos feature kikerült belőle. Ha egészen erősen szabványos css-t, html-t használsz, akkor különösebb gond nem is lesz az IE10-en megjelenítéskor.
Ráadásul a conditional comment-et se jól használtad, ez a helyes szintaktika:
<!--[if IE]>
This content is ignored in IE10 and other browsers.
In older versions of IE it renders as part of the page.
<![endif]-->[ Szerkesztve ]
Én kérek elnézést!
-
martonx
veterán
Aha, ActiveXObject.
Hát ezzel jól megszopattad magad, bár elméletileg működnie kellene, mégis ahogy helyetted rágugliztam, tele vannak a fórumok hasonló problémákkal.
Két megoldási lehetőséged van:
1. elkezded az IIS-t buzerálni, hátha egyszercsak működni fog, én elsőre a Full Trust hiányára tippelnék (már ha ilyet egyáltalán lehet IIS 5.1-en állítani).
2. újraírod normálisan, plusz kidobod az XP-s régi fost is, és valami normális helyen hosztingolod, akár ingyenesen.A 2-es módszer pár órát fog igénybe venni (ez persze programozói tudás függvénye), és biztos lesz a siker. Az 1-es módszerrel napokat el lehet szórakozni, de az is lehet, hogy 5 perc múlva már jó is lesz.
Én kérek elnézést!
-
#5131
martonx
veterán
Sk8erPeter
#5130
martonx
veterán
válasz
Sk8erPeter
#5130
üzenetére
Ez inkább fordítva szokott gondot okozni, nem? A linux case sensitive, a windows insensitive.
Én kérek elnézést!
-
martonx
veterán
Mondjuk ezen hosszan el lehetne filozofálni, hogy ez bug vagy feature (hozzáteszem RFC szabvány szerint az url-ek case inszenzitívek, ami vicces mert pl. a cookie-k meg nem azok), és az index.html valóban eltér-e az INDEX.HTML-től. Adatbázisoknál én szeretem a case szenzitivitást (vagy hogy mondják ezt magyarul), url-eknél meg bosszant.
Én kérek elnézést!
-
martonx
veterán
A böngészők szabványosodnak. Amit az egyik verzióban még megengedtek, azt a következőben már lehet, hogy nem. S mivel automatikusan frissülnek (FF, Chrome már régóta, IE10 óta az IE is), így bármikor észreveheted, hogy ami egyik nap még ment, másnap már nem működik.
Én kérek elnézést!
-
#5251
martonx
veterán
fordfairlane
#5250
martonx
veterán
-
martonx
veterán
válasz
cidalain
#5264
üzenetére
"az IE eléggé furcsán működik ilyen szempontból" - ezzel azért vitatkoznék, pláne ha már csak IE10+ kell foglalkozni az IE-vel.
Inkább úgy mondanám, hogy van egy csomó css parancs, amik böngésző specifikusak.
Pl: -webkit- kezdetűek Chrome, Opera, Safari specifikusak (hehe vicces, mert attól, hogy webkit, nem biztos ám, hogy mindháromban létezik az adott parancs, illetve ugyúgy viselkednek...)
-ms- kezdetűek IE specifikusak
és így továbbA legjobb ilyen téren az IE és az FF, mert ők már egy csomó szabvány dolognál prefix nélkül működnek. Nagyon várom, hogy egyszer végre a Chrome is kidobjon egy rakás felesleges prefixet.
Én kérek elnézést!
-
#5277
martonx
veterán
PumpkinSeed
#5276
martonx
veterán
válasz
PumpkinSeed
#5276
üzenetére
Mondjuk folyó szöveget nem kellene div-el tagolni, akkor már inkább span. De igen, az elv ez.
Én kérek elnézést!
-
#5295
martonx
veterán
Sk8erPeter
#5294
martonx
veterán
válasz
Sk8erPeter
#5294
üzenetére
Wordpressnél is megoldották normálisan. Sőt nem tudok olyan CMS-ről, ahol ne lenne out-of-the-box megoldva.
Én kérek elnézést!
-
martonx
veterán
Az a baj, hogy valami miatt (talán mert ennek a legegyszerűbb átlátni magát a forráskódját is), a wp felhasználók, sőt a wp fejlesztők sem tudják hogyan is kellene normálisan szabályosan wp-zni. És van aki még könyvet is ír... Tragikus.
Egyébként kismillió fordító plugin van hozzá: link a legelső szerintem része az alap telepítő csomagnak.
[ Szerkesztve ]
Én kérek elnézést!
-
#5309
martonx
veterán
Sk8erPeter
#5307
martonx
veterán
válasz
Sk8erPeter
#5307
üzenetére
Szvsz, meg az adatbázis nem azért van, hogy fordítást tároljunk benne. Persze lehet, nem tiltja senki. Jellemzően pár száz, pár ezer kulcsokkal dolgoznak a fordítások. Ezek már miért ne lehetnének file-ban? Ne tegyünk úgy, mintha az adatbázis valami csoda lenne. Az is file-ban tárolódik ugyanúgy a lemezen
(kivétel a NoSQL, bár még X időnként az is szinkronizálja magát file-ba a háttérben).
Egy xml-en végigrohanni semmivel nem tart tovább, mint elindítani húszszor egymás után, hogy select ize from forditas where key = valami. A húsz-al arra céloztam, hogy mondjuk 20 elem fordítását kell lekérdezni az oldal rendereléséhez. Sőt lehet hogy, az xml nyerne.Én kérek elnézést!
-
#5316
martonx
veterán
Sk8erPeter
#5311
martonx
veterán
válasz
Sk8erPeter
#5311
üzenetére
Bocsánat, szokásomhoz híven nem CMS-ben gondolkoztam, amikor írtam a felvetésemet, amivel igaziból csak arra akartam reflektálni, hogy abszolút nem lehet olyan magabiztossággal kijelenteni az adatbázisban tárolt fordításról, hogy az a jó megoldás, mint ahogy tetted. Lehülyézni végképp nem állt szándékomban, bocsánat.
És az én nézőpontomból nézve, valóban nincs semmi értelme db-ben tárolni a frodításokat, persze miért ne lehetne, csak értelmetlen, hiszen a benne tárolt relációs adatokhoz semmi módon nem kapcsolódnak, semmi pluszt nem ad a a db-ben tárolás a fileban tároláshoz képest.
Ugyanakkor a te CMS-es nézpontodból, ahol a UI összeállításához szükséges minden egyéb információ is db-ben tárolódik, és minden hiperdinamikusan állítható, össze-vissza paraméterezhető, ott valóban ez lehet a jobb megoldás, és ekkor lehet, hogy még relációban is állnak más egyéb adatokkal.
Ráadásul úgy érzem kölcsönösen félreértettük egymást. Egyrészt ezek szerint te sem gondoltad az egyetlen üdvözítő útnak a db-ben tárolt fordítás megoldását, én sem gondoltam egyetlen üdvozítő útnak a file-ban tárolást. Akkor már említsük meg a harmadik megoldást is, amikor teljesen külön lokalizáció függő templateket, html-eket használ valaki, amit rohadt macerás ugyan karban tartani (pláne minél több nyelvet kell támogatni), de teljesítményben mindkét fenti megoldásnál jobb.
"Másik: amikor az ÖSSZES fordításban keresgélek - amire van lehetőség Drupalban - akkor szerinted tényleg az lenne a legjobb, ha az adott esetben száz telepített modul (úgy, hogy egyes moduloknak lehetnek almoduljai, akár 10 almodulja is lehet, épp a modularitás jegyében, hogy azok kikapcsolhatóak legyenek), 3 smink, és a core fordítási fájlját is összekaparná, parse-olná, és kinyögné valahogy pár másodperc után a végeredményt, hogy melyik fájlban találom az adott stringrészletet?"
Nyelvenként egy po file-t lehet nyitva tartani a jobb po editorokban, és keresni bennük a pillanatok műve.Szerintem elég jól körüljártuk a témát, és bocsánat ha túl lekezelő lettem volna, nem volt szándékomban megbántani.
Én kérek elnézést!
-
#5318
martonx
veterán
Sk8erPeter
#5317
martonx
veterán
válasz
Sk8erPeter
#5317
üzenetére
Én kettő konkrét példát tudok mondani. Az egyik az általában mostanában használt Orchard CMS. Itt is adatbázisban van tárolva a fordítás. Miközben ez egy ASP.NET MVC-re épülő CMS. Ez mindjárt fontos lesz.
Admin felületről lehet fordítgatni benne a cuccokat, egész korrektül megcsinálták. CMS-hez talán tényleg ez a megoldás a legjobb, mivel amúgy is minden content az utolsó betűig az adatbázisban van. Ha már úgyis adatbázis kell a legkisebb hello world-höz is, akkor kézenfekvő, hogy egyúttal onnan rögtön a nyelvnek megfelelő szöveget vegye ki a rendszer.A másik az általam napi szinten használt ASP.NET MVC keretrendszer (illetve a többiek is saját megoldásokat hoztak, az igaziból mindegy, hogy PHP vagy ASP.Net vonalról beszélünk). Itt pedig .resx fileokban vannak tárolva a fordítások (ugyanaz, mint a .po fileok). Minden file egy nyelvet jelent, Visual Studioból, vagy Resx editorból szerkeszthetőek. Egyszerre több file-t párhuzamosan kezel az editor, nagyon kényelmes használni, jelzi a hiányzó fordításokat, bármilyen nyelven is legyenek azok, és gyors is. Képzeld el, hogy Notepad++-ban megnyitsz mondjuk 3 db egyenként 1Mb-os file-t és általános szöveg keresést csinálsz bennük. Mennyi idő alatt van meg a keresés első eredménye, bármelyik file-ban is legyen a keresendő szó? Gyakorlatilag rögtön, még ha ez nyilván ms nagyságrendő is a valóságban. Bevallom annyira sosem mentem a dolgok mélyére, hogy a gyakorlatban elemezgessem, hogy az ASP.NET MVC aztán hogy szedi ki ezekből az xml fileokból a fordításokat, de hogy pillanatok alatt megvan azt látom, mérem. Szvsz teljesen normális 1-1 pár száz kb-os, folyamatosan használatban lévő file tartalmát memóriában tartani, de szerintem azokat megnyitogatni és realtime olvasni is minimális idő. Anno, amikor pénzügyi vonalon dolgoztam és XML feldolgozó programokat is kellett csinálnom, én is meglepődtem azon, hogy milyen iszonyatosan gyors tud lenni a bennük való keresés.
De vegyük tovább. A nem CMS-ek, template fileokkal dolgoznak, és ezeknél nem azt írod a template-be, hogy <h1>Hello world</h1>, hanem <h1>helloworldfordításkulcs<h1>. Aztán majd a motor a template feldolgozásakor, a html kimenet legenerálásakor egyúttal kiszedi hozzá a szükséges fordítást is, miért is kellene ehhez adatbázis? És hidd el, ez így jóval gyorsabb, mint db-hez fordulni mindenféle protokollon keresztül (arról nem is beszélve, hogy a db külön gépen is szokott lenni), aztán megkérni, hogy adja már ide a helloworldfordítás kulcshoz tartozó értéket, pláne ha egy oldal kigenerálásakor kell vagy 20-50 ilyen lekérdezés. Persze ennél a megoldásnál is előjön pluszban adatbázisban fordítás tárolás is, ha mondjuk webáruházról beszélünk, és a termék megnevezés, szöveges adatai több nyelven is meg kell, hogy legyenek, de ez nyilvánvalóan relációs adat.És ahogy mondtam van a harmadik megoldás, amikor van egy helloworld.html-ed, meg egy sziavilag.html-ed, és a komplett cuccot az adott nyelven írod meg. Nyilván ez a leggyorsabb teljesítmény szempontjából, mert se db-hez, se .po file-hoz nem kell fordulnia a rendszernek. De amikor rájössz, hogy egy többször előforduló szöveget át akarsz írni bennük, és mondjuk 5 nyelvet kezel a rendszer és van 30 fileod, akkor ez nem kevés szívást jelenthet.
Leírok még két szempontot, az adatbázis nem erre való érvemre. A komolyabb alkalmazásoknál rendre az adatbázis a szűk keresztmetszet. Általában annak is örülünk, ha a rengeteg adatot kezelni tudja, nem hogy még azzal is terheljük, hogy ja de a helloworldfordítás értékét is add már ide, mert a címhez be kellene illesztenem.
Másrészt vegyük észre, hogy a hoszting cégeknél a sima lemez kapacitás jellemzően több, mint az SQL tárhely. Sőt felhőben hosztingolva pl. a lemez kapacitás szó szerint szinte ingyen van, míg az SQL-es adattárolásnál azért zsebbe kell nyúlni.Én kérek elnézést!
-
#5352
martonx
veterán
haromegesz14
#5351
martonx
veterán
-
-
martonx
veterán
válasz
cidalain
#5441
üzenetére
Hű te nagyon kevered a szezont a fazonnal.
Most őszintén, szerinted mennyi nem publikus könyvtárral rendelkezik egy webszerveren futó alkalmazás?
Ráadásul nehogy már a usernek kelljen kamu index.html-ekkel elfednie a webszerver beállításainak a hiányosságait.
Abszolút alap, hogy web szerver soha nem listáz ki semmit. Innen indulunk minden webszervernél. Aztán jöhetnek a kivételek (ftp, webdav, akármi), de mindig ez az alap, hogy könyvtár tartalma soha nem listázható ki.
Bárhogy nézed, ez szerver beállítási probléma.Én kérek elnézést!
-
#5452
martonx
veterán
Sk8erPeter
#5451
martonx
veterán
válasz
Sk8erPeter
#5451
üzenetére
"Ha a fejlesztő szemszögéből nézzük, akkor pedig az ő felelőssége megoldani, hogy ne lehessen csak úgy kotorászni a webszerver publikus könyvtárában."
Annyit tennék azért még hozzá, hogy szvsz nem a fejlesztő feladata konfigurálni egy webszervert. Ez tipikusan rendszergazdai, üzemeltetői feladat. Noha nyilván gyakran nem ilyen tiszták a határvonalak, de szvsz az régen rossz, amikor a fejlesztő a nyilvánvaló üzemeltetői hiányosságot kell, hogy javítgassa, foltozza.
Szegény cidalain-nék nem értik miről beszélünk, úgyhogy mondjuk már ki végre egyértelműen:
Szarul van konfigurálva az apache (vagy bármilyen webszerver, nem derült ki az eredeti hsz-ből a webszerver pontos típusa), és ekkor nem az a megoldás, hogy fejlesztőként elkezdünk ilyen - olyan kókány megoldásokkal együtt élni a nyilvánvaló konfigurációs hibával, hanem elintézzük, hogy legyen normálisan konfigurálva.
Én kérek elnézést!
-
martonx
veterán
Ideális esetben szerintem a tanulási folyamat így zajlik (nyugodtan kövezzetek meg érte, illetve az élet sosem ideális)):
1. saját kezűleg barkácsolsz, közben rengeteget tanulsz.
2. rájössz, hogy a CMS-ek ugyanezt tudják, csak jobban, átállsz rájuk, közben rengeteget tanulsz.
3. rájössz, hogy a CMS-eknek komoly hátrányai vannak, átállsz a frameworkök használatára, közben rengeteget tanulsz.Én kérek elnézést!
-
#5487
martonx
veterán
Sk8erPeter
#5483
martonx
veterán
válasz
Sk8erPeter
#5483
üzenetére
Ahogy ezt már sokszor átbeszéltük, egy feladatot sokféleképpen meg lehet oldani. Szvsz a Drenti által említett eset tipikusan olyan, amit meg lehet oldani framework-kel is, meg CMS-el is, de egyértelmű, hogy a CMS-nek itt már pozitív hozadéka nem lesz, ellenben sorra fognak előjönni a negatív hozadékok.
Épp mostanában jártam úgy (az esetet ismered is www.realeyesit.com), hogy egy komplexebb feladatot CMS-el oldottunk meg, mert az elején még az tűnt a jobb megoldásnak, aztán a végén 3 hónapot fejlesztettünk azzal is, és a végeredmény akkor sem lett olyan, mintha 3 hónap alatt az alapoktól megcsináltuk volna frameworkkel.
Én kérek elnézést!
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Másrészt van is megrendelése bőven, mert még mindig többségben vannak azok, akiknek fontosabb, hogy szinte ingyen legyen, mint az, hogy valóban jó is legyen a végeredmény.
Linux konzol ablak, meg a phpmyadmin? 
(kivétel a NoSQL, bár még X időnként az is szinkronizálja magát file-ba a háttérben).
Új hozzászólás Aktív témák
Hirdetés
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest