Archívum - Ápr 6, 2013
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).
Opera confirms it will follow Google and ditch WebKit for Blink, as part of its commitment to Chromium
Az Opera lesz a második böngésző, ami a Blink megjelenítőt használja
■