Archívum - Ápr 6, 2013 - Fórum téma
Favicon-ok kezelése
Sziasztok,
Amikor letöltöm a HTML5Boilerplate csomagját (initializr), akkor 7-féle favicon szerepel a gyökérben: 6 db "apple-touch-icon" kezdetű png és 1db jól megszokott "favicon.ico" fájl. Az index.html-ben nem szerepel egyik ikonra való utalás sem (<link …>). Ez vajon miért van így? Automatikusan felimserik az eszközök ezeket a neveket? Ill. van három 57x57 px-es ikon: "apple-touch-icon.png", "apple-touch-icon-precomposed.png" ill. "apple-touch-icon-57x57-precomposed.png". Milyen jelentést takar a precomposed kifejezés? Van egyáltalán különbség a három verzió között? Hogyha nem a gyökérben tárolom a favicon-okat az jelenthet problémát?
■ Amikor letöltöm a HTML5Boilerplate csomagját (initializr), akkor 7-féle favicon szerepel a gyökérben: 6 db "apple-touch-icon" kezdetű png és 1db jól megszokott "favicon.ico" fájl. Az index.html-ben nem szerepel egyik ikonra való utalás sem (<link …>). Ez vajon miért van így? Automatikusan felimserik az eszközök ezeket a neveket? Ill. van három 57x57 px-es ikon: "apple-touch-icon.png", "apple-touch-icon-precomposed.png" ill. "apple-touch-icon-57x57-precomposed.png". Milyen jelentést takar a precomposed kifejezés? Van egyáltalán különbség a három verzió között? Hogyha nem a gyökérben tárolom a favicon-okat az jelenthet problémát?
SSL certificate - hiányzik a root CA (megoldva :( )
Update: bocs, egyelőre úgy fest, tárgytalan...
Tanulságul az utókor számára itt hagyom, de ha valaki admin erre jár, nyugodtan törölheti is!
Routeremen firmware-t cseréltem. Tomato, mivel openwrt nincs rá. Korábban, openwrt alatt pillanatok alatt összedobtam ugyanezt a konfigurációt, most meg x ideje megy az anyázás. Előbb a friss verzióról derült ki, hogy a routeremen kb. 20 perc egy boot. Most meg harmadik napja nyűglődtem a tanúsítványokkal, mert akárhogy debuggoltam, nem kaptam értelmes hibaüzenetet.
(olyan apróságokat, hogy a szükséges make-et nem tették be a függőségek közé a készítők, az openssl meg hátrébb áll a path-ban, mint a firmware saját, lebutított verziója... már meg sem említek)
Végül kínomban már azt próbáltam, hogy egy Ubuntura felhúzott freeradius-t akartam használni. Előbb csak tanúsítvány készítéshez, de azokkal a tanúsítványokkal a routeren lévő, korábbi verziójú SSL nem boldogult, utána magát az ubuntu freeradius-át próbáltam bekonfigurálni, az sem ment.
A lokálisan, saját csomagjaival gyártott tanúsítványokkal meg bármit csináltam, akárhogy konfigurálgattam a freeradiust és az openssl-t, nem akart működni.
Húsz perce jött az ötlet: stabil debian. Az régebbi, mint az ubuntum! Freeradius fel, bootstrap script futtatás, make client, az egész könyvtár át a routerre a megfelelő könyvtárba és... Máris működik.
Már csak egy elérhető árú, jó minőségű, 5GHz-et is tudó router kellene, ami támogatja az openwrt-t is. Mert ebből a tomatos töketlenkedésből k.ra elegem van, na!
Tanulságul az utókor számára itt hagyom, de ha valaki admin erre jár, nyugodtan törölheti is!
Routeremen firmware-t cseréltem. Tomato, mivel openwrt nincs rá. Korábban, openwrt alatt pillanatok alatt összedobtam ugyanezt a konfigurációt, most meg x ideje megy az anyázás. Előbb a friss verzióról derült ki, hogy a routeremen kb. 20 perc egy boot. Most meg harmadik napja nyűglődtem a tanúsítványokkal, mert akárhogy debuggoltam, nem kaptam értelmes hibaüzenetet.
(olyan apróságokat, hogy a szükséges make-et nem tették be a függőségek közé a készítők, az openssl meg hátrébb áll a path-ban, mint a firmware saját, lebutított verziója... már meg sem említek)
Végül kínomban már azt próbáltam, hogy egy Ubuntura felhúzott freeradius-t akartam használni. Előbb csak tanúsítvány készítéshez, de azokkal a tanúsítványokkal a routeren lévő, korábbi verziójú SSL nem boldogult, utána magát az ubuntu freeradius-át próbáltam bekonfigurálni, az sem ment.
A lokálisan, saját csomagjaival gyártott tanúsítványokkal meg bármit csináltam, akárhogy konfigurálgattam a freeradiust és az openssl-t, nem akart működni.
Húsz perce jött az ötlet: stabil debian. Az régebbi, mint az ubuntum! Freeradius fel, bootstrap script futtatás, make client, az egész könyvtár át a routerre a megfelelő könyvtárba és... Máris működik.
Már csak egy elérhető árú, jó minőségű, 5GHz-et is tudó router kellene, ami támogatja az openwrt-t is. Mert ebből a tomatos töketlenkedésből k.ra elegem van, na!
WEB 2.0
Hosszú lesz.
Tegnap elolvastam, hogy a PHP halálra van ítélve. Azt hittem valami klikkvadász bulvár hír, de marhára megfogott és nagyon igaza van.
Emellett kavargott még a fejemben, hogy létezik Node.js ami aszinkron elvekre épül, és nem értjük, hogy mire jó ez. kemma épp a REST-ről kérdezgetett.
Mindeközben mindennapi munkám során elmozdultam olyan irányba, hogy amit tudok kliens oldalon csinálok meg, és tényleg a szerver csak küldjön nekem adatot, meg dolgozza fel amit küldök neki. HTML-t generálok inkább kliens oldalon, amíg csak azon küzd a júzer, hogy a szervernek elküldhető adathalmaz létrejöjjön, nem röpködnek a http kérések.
ez volt a bevezető.
egyre inkább úgy gondolom, hogy ha mondjuk MVC alapokon gondolkodunk, akkor nem annyira egyértelmű, hogy mind a három összetevőnek a szerver oldalon kell futnia. sőt azt gondolom, hogy V (megjelenítés, felület előállítás) és C (események kezelése) komponenseknek inkább a kliens oldalon van a helyük, sőt azt sem tartom extrém dolognak, hogy a adott esetben az üzleti logika (egy része) is futhat kliens oldalon, aztán ha kell szinkronizál a szerverrel (van erre példa).
lesz aki megöl ezért :), de szerintem semmi akadálya, hogy asztali alkalmazásokat hozzunk létre HTML, CSS, JS alapon. annyi hogy a kódbázist, ha épp nincs meg a szervernek el kell küldenie. Nem is kell az egész csak épp az amire szükség van.
és itt jönnek képbe a bejegyzés elején említett dolgok. semmi szükség rá, hogy a szerver oldali folyamatok felhasználó alapon fussanak (1 felhasználó (kérésenként, legalább) egy külön process).
Tegnap elolvastam, hogy a PHP halálra van ítélve. Azt hittem valami klikkvadász bulvár hír, de marhára megfogott és nagyon igaza van.
Emellett kavargott még a fejemben, hogy létezik Node.js ami aszinkron elvekre épül, és nem értjük, hogy mire jó ez. kemma épp a REST-ről kérdezgetett.
Mindeközben mindennapi munkám során elmozdultam olyan irányba, hogy amit tudok kliens oldalon csinálok meg, és tényleg a szerver csak küldjön nekem adatot, meg dolgozza fel amit küldök neki. HTML-t generálok inkább kliens oldalon, amíg csak azon küzd a júzer, hogy a szervernek elküldhető adathalmaz létrejöjjön, nem röpködnek a http kérések.
ez volt a bevezető.
egyre inkább úgy gondolom, hogy ha mondjuk MVC alapokon gondolkodunk, akkor nem annyira egyértelmű, hogy mind a három összetevőnek a szerver oldalon kell futnia. sőt azt gondolom, hogy V (megjelenítés, felület előállítás) és C (események kezelése) komponenseknek inkább a kliens oldalon van a helyük, sőt azt sem tartom extrém dolognak, hogy a adott esetben az üzleti logika (egy része) is futhat kliens oldalon, aztán ha kell szinkronizál a szerverrel (van erre példa).
lesz aki megöl ezért :), de szerintem semmi akadálya, hogy asztali alkalmazásokat hozzunk létre HTML, CSS, JS alapon. annyi hogy a kódbázist, ha épp nincs meg a szervernek el kell küldenie. Nem is kell az egész csak épp az amire szükség van.
és itt jönnek képbe a bejegyzés elején említett dolgok. semmi szükség rá, hogy a szerver oldali folyamatok felhasználó alapon fussanak (1 felhasználó (kérésenként, legalább) egy külön process).
