Weblap - IntoMusic - vélemény kérés
Sziasztok,
szeretném bemutatni, és véleményt kérni a következő weboldalamról.
intomusic.hu
Köszönöm ;)
■ szeretném bemutatni, és véleményt kérni a következő weboldalamról.
intomusic.hu
Köszönöm ;)
Friss blogmarkok
- Web Akadálymentesítési Útmutató (WCAG) 2.1 – nyilvános munkaterv – Megjelent a WCAG (Web Akadálymentesítési Útmutató) 2.1 nyilvános munkaterv (0)
- MongoDB Apocalypse Is Here as Ransom Attacks Hit 10,000 Servers – Több tízezer védtelen MongoDB szerverre csaptak le hackerek (2)
- 12 Signs You’re Working in a Feature Factory – A cél nélküli funkciógyártás néhány tünete (0)
- Translatable, custom dates in Twig templates of Drupal 8 – Saját dátumok megjelenítése, fordíthatóan a Drupal 8 smink rétegével dolgozva (0)
- NativeScript – Cross-Platform Native Development with Javascript – Fejlesszünk natív mobilalkalmazást JavaScripttel (0)
- GitHub Security Update: Reused password attack – Érdemes bekapcsolni a kétfaktoros azonosítást, ha a GitHub jelszavunkat más oldalakon is újra felhasználtuk (17)
- UX Design könyv – Hogyan tervezz felhasználóbarát és szerethető alkalmazásokat? (0)
- Introducing unlimited private repositories – Megváltozik a GitHub díjszabása: minden előfizetéshez korlátlan számú privát repository jár (0)
- Drupal 8 Twig: add custom CSS classes to menus (based on menu name) – Saját elképzeléseink szerinti CSS osztályok (automatizált) hozzáadása a Drupal 8 menüihez (0)
Cikkajánló
gerzson:
A regexről – másképp
janoszen:
Sessionmentes weboldalak
chikk:
XAML bemutatása
Friss csiripek
Csiripek betöltése…
Aktív fórum témák
Új fórum témák
Archívum
| H | K | Sze | Cs | P | Szo | V |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | 1 | 2 | 3 | 4 | 5 |
Egész jó
<meta name="description" content="">nincs kitöltve, ez SEO hiba.Pár helyen szerepel
<div class="slider" style="background:#c0392b;">inline style, ettől tartózkodni kéne, főleg ha van is rajta class attribútum.Nem túl szerencsés angol és magyar elnevezéseket keverni:
<a href="/assets/belep/social.php?mibe=google" ...Idővel nem fogod tudni, hogy az adott dologra most angolul vagy magyarul kéne hivatkozni.
Tartalom / szolgáltatás:
- Elsőre az jön le, hogy ugyanazt próbálja nyújtani, mint sokan mások is - semmi okom rá, hogy váltsak. (meg is kell győzni a látogatót, hogy használja pl. a Deezer helyett: írd le, hogy miért jobb a tiéd mindegyiknél.)
- Rólunk: ez inkább külön oldal lenne, ott viszont jóval részletesebb. Egy "cég" (szolgáltatás) 2 éve ha leírható 2 mondatban, akkor ott senki nem csinált semmit.
Nem kérünk pénzt, és nem korlátozzuk a zenelejátszást!
Hozd össze ismerőseidet, és fedezz fel új dalokat!
Backend-ből nem láttam semmit, engem inkább az érdekelne.
Ha túl kritikus voltam, akkor ne törődj vele, az a szándék vezérelt, hogy amennyiben akarsz rajta javítani, akkor adjak pár tippet, hogy hol érdemes.
SZERK.: osszd - Hozd. Sanszos, hogy a kettő közül az egyik helyesírási hiba.
Köszi
meta-t javítottam, inline style-k javítása is tervben. ;)
URL-ben az angol és a magyar nyelvnek a keveredésének az oka, hogy jelenleg próbálom a régi magyar URL-eket angolra cserélni, és még nincs mindenütt cserélve - bár a fontosabb (átlagfelhasználók által látott) linkek nagy része Angol. ;)
Szolgáltatás terén tulajdonképpen 2015-ig az egyetlen konkurenciája a bop.fm volt, de azt - ha jól tudom felvásárlás miatt - megszüntették. Igaz ismerek még 2 kisebb oldalt, de azok csak 3 oldalról támogatják a lejátszást (SoundCloud, Deezer, YouTube), míg az IntoMusic 14 oldalt is támogat (na jó, Spotify támogatása elég részleges..)
Éppen ezért az oldal az általad említett Deezer-nek pl. nem konkurenciája, hiszen pont arra épül. Hogy miért jó az egész? Ennek egy rövid története van:
Az egész úgy kezdődött, hogy a zippyShare-ról való zenelejátszást nem találtuk túl kényelmesnek - mivel hogy a gyári lejátszó a play/pause-n kívül tulajdonképpen semmit nem tud - így felvetődött az ötlet egy lejátszó-oldal létrehozásán (IntoMusic 1.0). Majd később előjött az az ötlet is, hogy milyen jó lenne, ha a sok oldalon elérhető tartalmakat ehhez hasonló módon egy oldalon lehetne elérni, a jelenlegi sok helyett (2.0-s verzió). Később ez bővült azzal, hogy jó lenne a saját, felhőben lévő tartalmak (oneDrive, Google Drive stb.) elérését is megcsinálni.
(Utlosó, Backend-es érdeklődésedre:) Fejlesztés közben nagyon sok dolog felmerült a szolgáltatással kapcsolatban, 2.0 megjelenésével tulajdonképpen újra kellett építeni a teljes adatbázis-szerkezetet, és zenekereső rendszert, annyi duplikáció került a rendszerbe, illetve a sok tartalomnál a sima listázás felhasználói részről áttekinthetetlen lett, így alakult ki a most látható toplista oldal. Ezeken kívül pedig a különböző API-k rendezése, adatainak feldolgozása (különböző adatok, mégis meg kell találni a megegyező zenéket) és ezek használata mellett is normális oldalbetöltési sebesség elérése volt talán a legnehezebb feladat.
</story>
Tehát vissza az oldal szolgáltatásaira: Az oldal célja az, hogy megszüntesse azt az összevisszaságot, hogy - a legnépszerűbb tartalmakat kivéve - tulajdonképpen semmi sem érhető el egy szolgáltatás alatt, ezért ez az oldal segít a lehető legtöbb forrásból tartalmazó zenéket mégis egy lejátszóba "összehozni". (Ezt próbálja meg bemutatni a főoldal, úgy tűnik, még változtatni kell rajta, pl. egy részletesebb leírás hozzáadásával. ;))
Mi garantálja, hogy holnap is leérhető lesz az oldal?
Tulajdonképpen semmi, a Grooveshark vagy a bop.fm (hogy témába illő oldalakat hozzak fel) is megszűnt egyik napról a másikra, pedig milliós látogatottságuk volt előtte több éven át. Mondhatom, hogy nem fogom megszüntetni az oldat, de ki hinné el nekem? (Egyébként tényleg nem tervezem a megszüntetését :D ;) )
Hogy miből él meg az oldal?
Terveim (inkább reményeim) szerint az oldalon megjelenő hirdetések néhány éven belül vissza fogják hozni az oldal üzemeltetésének árát. De ha mégsem, akkor sincs baj, mert én is az oldal felhasználója vagyok, és napi rendszerességel használom, és amíg nincs alternatívája, addig ez így is fog maradni.
A SZERK részben leírtakat sajnos nem teljesen értem, nem tudom, mire írtad ezt. ;)
És még egyszer köszi a visszajelzéseket. ;)
van még olyan, hogy
nekem most hirtelen csak ennyi, hajrá!
Van még :)
Hozd össze ismerőseidet, és fedezz fel új dalokat!
„osszd”: ismeretlen
Javaslatok: ossz, oszd, osszad, ossza
Description jó lett, szerintem a title is lehetne kicsit több, pl "IntoMusic - minden zene egy helyen".
Regisztráció form:
- Belépni hol lehet, ha már regisztrált valaki? Belépés formot nem látni sehol.
- Ezt egy kicsit jobban meg kéne fogalmazni, első és utolsó szó ismétlés:
- Én úgy tudom, hogy amennyiben bármiféle ÁSZF jellegű dolgot el kell fogadni a regisztráláshoz / használathoz, akkor azt ott helyben, ahol be kell pipálni, be is kell linkelni. Így hirtelen nem is láttam "az Into.hu és az IntoMusic szabályzatát." sehol.
- Nem fogadta el a "+" jelet e-mail címben, pedig lehet benne.
- Sikertelen regisztráció után elveszett az összes megadott adatom a formból.
- Sikeres reg után beállítások -> színséma - kék: szétesett az oldal, mintha nem lenne css. F5 után helyreállt.
- Nincs jelszó megerősítése. Ez azért fontos, hogy megvédd a user-t, ha véletlen elgépeli. Akkor nem lesz egyforma a kettő.
- Belépés után már látható némi ÁSZF, van is benne helyesírási hiba:
De nem szerencsés az "itt típusú" link, mert ha valóban itt, akkor nem kell linkelni, mert helyben vagyunk... :)
- Kilépés után az /en-en URI-ra irányított, előtte hu-hu volt. Amúgy mi célt szolgál a duplikált nyelvi kód? Azon túl, hogy csúnya (és nem is kéne URL-ben lennie, session / cookie simán alkalmas rá).
- Nincs e-mailes aktiválás: akár másvalakiét vagy nem létező címet is megadhatok.
Apropó, sütik.. PHPSESSID nem szerencsés név... És az id-t is jobb magadnak generálni, és sűrűn cserélgetni. Az ördög nem alszik.
Ha nem titok, kíváncsi lennék régi és új db szerkezetre.
Ha teszel ki valami login formot, akkor majd még tesztelném, pl biztonságra, míg le nem tiltasz. :)
Aztán lehet, hogy pár "nótát" is meghallgatnék, "hátha itten jobban zeng".
Így már érthető, javítottam
- Menüben ott a belépés gomb. Kapott kiemelést. ;)
- emailban a + jelet már a HTML5 is visszadobta, vagy csak a PHP?
- színtéma választás hibát nem sikerült reprodukálnom... JavaScript hibát nem kaptál véletlenül?
- Szabályzatot javítottam, kiegészítettem.
- URL-ben a nyelvi kódok a keresők miatt vannak, hogy minden nyelven megtalálják az oldalakat. Kilépés után minden törlődik session-ból, így az is, hogy milyen nyelven böngésztél addig, így automatikusan a böngésző által küldött adatokból állapítja meg a nyelvet, ha az URL-ből hiányzik. Azért látszik duplikáltnak, mert az első az oldal-nyelv, a második a régió beállítása. (tehát angol esetén lehet en-us, en-au, en-gb is... , pont úgy, mint a www.microsoft.com/hu-hu oldalon is pl.)
- PHPSESSID név helyett miért jobb más?
Szia, OFF, de talán mégsem,
OFF, de talán mégsem, és a Session szóról jut eszembe: Ha sok felhasználót vártok, és egyszer csak lekönyököl a szerver, akkor mi módon tudtok skálázni?
A session itt azért jön szóba, mert ha később valamiféle loadbalancigot kell alkalmazni (tehát több szerverről kell kiszolgálni a rendszert) terhelés miatt, akkor lehet kicsit gondban lesztek, mert ha X szerveren elindul a felhasználó sessionje, és a következő kérés mondjuk Y szerverre érkezik, akkor ott az előző session nem fog létezni; bár van erre is megoldás, hogy ne legyen nagy probléma.
Web service-en keresztül ajánljátok ki a rendszer működését (pl.: REST API)? Mert ha igen, akkor ott érdemes stateless maradni, vagyis a session használatát mellőzni, így könnyeben tudtok horizontálisan bővíteni.
Milyen keretrendszert használtok?
Felejtős
Az a tapasztalatom, ha
Skálázás
Értem; attól függetlenül, ha
Hogyan?
Tehát. Tegyük fel, hogy úgy
Ha a backend és a frontend ilyen módon szét van választva, akkor a rétegek már viszonylag jól karbantarthatók.
Az is igaz, hogy egy ilyen backend esetében nem árt, ha stateless-ek maradunk, tehát nem használunk munkamenet.
Szerintem ezen a ponton még nincs többlet munka.
Ha a rendszer terhelődik, mert ügyes volt mindenki és gyűlnek a felhasználók, akkor ezt az architektúrát már egyszerű skálázni, mégpedig azért, mert a backendet annyi szerveren tudjuk még üzemeltetni, amennyin kell (vagy csak növeljük az instancek számát amazonban :)); plusz a stateless megoldás miatt sem kell aggódni a sessionök miatt.
Próbáltam röviden összeszedni a gondolataimat, és leírni az általam vélt összefüggést a három említett fogalom között. Ha így sem érthető, akkor megpróbálom másképp, mégegyszer.
Még mindig nem áll össze a kép
Szép dolog az állapotmentesség, csak nem mindig oldható meg a fenti architektúrával, már a legegyszerűbb boltnál is a kosárkezelés felhasználónként egyedi.
Attól függ minden, hogy mi a backend kimenete.
A szerveroldali PHP és a
Jobb esetben igen, viszont ha kiindulsz pl egy Joomla, vagy egy WP oldalból, akkor tudhatod, hogy a HTML kódot is ugyanaz a PHP alkalmazás generálja ki, ami az adatbázis műveletekért is felelős.
Az állapotmentesség nem zárja ki a biztonságos felhasználókezelést.
Itt mire gondolsz pontosan?
ha kiindulsz pl egy Joomla,
Itt mire gondolsz pontosan?
van egy boltod, tegyük fel,
[GET] /api/kosar
ez visszaadja a kosarad tartalmát.
ez volna a nem állapotmentes verzió, mert attól függően, hogy ki hívja a kérést, más kimenetet ad.
nehezebb széttolni több szerverre, mert vagy kell valami session szinkronizáció, vagy sticky session kell.
lehet persze a kosár adatbázisban is (persze az előző verzió esetén is, és mondjuk a kosár id van csak a sessionben tárolva, de a session szinkronizáció akkor is probléma), és a kosár tartalmát kérdezheti a kliens úgy is, hogy
[GET] /api/kosar/1232314
ez volna az állapotmentes verzió, itt már könnyebb széttolni több szerverre a dolgot, mert lehet a php alatt is több szerver, de az adatbázis is széttolható több szerverre.
persze ettől még az állapotmentes kérés esetén is mehet egy cookie-ban (vagy inkább valami speckó headerben és akkor a hijack ellen is védetebb) valami token, ami azonosítja az adott felhasználót, ennek segítségével db-ből megkapjuk ki a júzer, és ha tudjuk hogy ki, akkor már azt is tudjuk ellenőrizni, hogy van-e jogosultsága hozzáférni az adott kosár lekéréséhez..
és viola (direkt írtam el), session nélkül működünk, könnyen skálázódunk.
Jó a levezetés/átvezetés!
(...) nehezebb széttolni több
Értem, amit mondotok, viszont átlagos eszközökkel ezek több problémát vetnek fel, mint amit megoldanak. Jó dolog a restful api, de kliensen is azt használod? Foglalkozni kell a SEO-val? Mert akkor szerveroldalon is kell HTML-t generálni. Kliensoldalon generáljuk csak? Valami javascriptes gányolás lesz a vége, ami tetűlassú, és csak a legújabb böngészőkben működik. Mindkét oldalon kell generálni? Akkor kétszer kell megírni a renderelést.
Jogosak a felvetések és az
Egy termék fejlesztése esetében mi pl csináltuk már azt, hogy egy jó WordPress oldal a landingpage, amibe tudunk dinamikus tartalmat is generálni, pontosan a SEO miatt (plusz van hozzá egy blog is), és innen tudsz navigálni egy másik oldalra, ahol fut az authentikációt igénylő alkalmazás (innetől kezdve niincs értelme a SEO kompatibilitásnak).
Itt egy AngularJS alapú kliensről és egy Java-s backendről (ami most 5 szerveren fut) beszélünk. Nem mellesleg a backendet használja még két mobil alkalmazás és egy böngészős bővítmény.
És igen, egy hírportál esetében nem teljesen ilyen architektúrára van szükség.
Mobil
Azért van szükség,
Például?
Tegyük fel, hogy van egy
Mobilon kifejezetten jó a kis méretű, akár lapozható kimutatásokat nézegetni, plusz tudsz reagálni egy kimutatás eredményére. Pl.: kommentelhetsz értékeket: "Az ott miért annyi?", vagy "Az ott miért csökken olyan gyorsan?"
Viszont,
Mobilon nem kényelmes felépíteni egy riportot, mert sok komponensből tudsz összerakni egyet, és azokat jó látni egy képernyőn, mert akkor látod, hogy miből tudsz építeni.
Weben sokkal hatékonyabban lehet kapcsolódó adminisztrációs tevékenységeket végezni, mint pl táblázatokat nézegetni, entitásokat karbantartani, hosszas kiértékelést írni, vagy éppen összeépíteni azt az adott riportot, esetleg hírlevelet gyártani.
És, hogy visszakanyarodjak: a fent említett mindenféle rendszer (pl.: SAP, vagy bármi middleware) a webes kliens és a mobil kliens is ugyanahhoz a backendhez kapcsolódik, mert egy központi helyen tudod kezelni a jogosultságokat, egy közös helyen nyúlsz adatbázishoz, logolsz, mérsz, stb.
A fenti példa természetesen ki van sarkítva szándékosan az összes ponton, ahol próbáltam szemléltetni a kérdésedre a választ; és ez egy általam nem lefejlesztett csak vizionált példa :).
Mobilon kifejezetten jó a kis
Érzem én, hogy nem tudlak
Ezért sarkítottam, vegyük a másik oldalát: Mennyire egyszerű egy 6-7 oszlopos 10-20 soros táblázat áttekintése, vagy akár egy értékelés megírása mobilon? Nem megoldhatatlan, sőt gyorsan megoldható, viszont, lesz az a felhasználó, aki azt fogja mondani, hogy "minden vágyam egy táblázat böngészése és egy kisregény megírása volt a mobilomon"?
Ha mobilon az ilyen és ehhez hasonló feature-öket nem használja, akkor miért fejlesszük bele? Másrészről, egy komoly termék esetén miért ne lennék elégedett egy natív appal, ami az oprendszerre optimalizált, szemben egy mobil böngészőben futó admin felülettel (ami mondjuk egy desktop böngészőben kiválóan használható)?
Bennem csak az motoszkál,
Ha engem nem tudsz meggyőzni, akkor hogy adtátok el a főnökötöknek?
Az rendben van, hogy a szolgáltatás admin- és felhasználók számára publikus felülete külön van, de hogy az utóbbira két klienst is elkészíteni, nekem soknak tűnik.
Amit elképzelhetőnek tartok, hogy bizonyos eszközök miatt, amiket csak natív alkalmazással lehet elérni, kell/érdemes külön mobilklienst készíteni. Érdekelne, hogy mik ezek.
Túl off
Nem lehetne erre egy új topic ot nyitni?
Már kb 30-40 comment nem a feltett kérdésre válasz + mobilon már nem is látni portrait. A srác meg nem találja meg a neki relevant infót, mert bő 90% nyi off közül kell kiválogatnia.
Gábor, az utolsó kérdésedre Szívesen mondok példát másik helyen.
Egyetértek! Szívesen
És igen, egy hírportál
Ha kliens oldalra rakod a
Másrészt, miért terheljem ugyanazt a szervert üzleti folyamatokkal és HTML generálással ha szét tudom választani?
Kliens
Ha ügyesen rakod össze az
Ami nagyobb erőforrást igényel, az egyedül a sablonok kezelése és a routing feloldása. A többi dolog (ajax kérések, jquery, javascript alapú validáció, stb) szinte az összes modern weboldalnak részét képezik.
Ha ezt valakinek a böngészője nem tudja feldolgozni, akkor ott vannak komolyabb problémák is szerintem.
fogalmak
Az pedig egy igen megerőszakolt elmélet, hogy ne használj session t.
Hát nem tudom... Én itt ezt
Az ott a REST
a webservice
és az RPC is. Ezek nem ugyanazok.
SZERK.: az itt lejött, hogy ti REST API-t nyomtok, de ez nagyon offtopic egy véleményt kérő node-on, és nem ez az egyetlen jó megoldás sem.
Húha
Belépés: inkább ezt a formot kéne állandóan kitenni, ha nincs belépve, reget a menübe. Fb stb login is login, nem reg.
Email: php. Ez valid lett volna, te dobtad el.
szín: rögtön f5 nyomtam, nem figyeltem... utána jó volt. Vmi cache lehet?
Url: nem csak így lehet, nyugodtan viheted tovább session v cookie is, de a választási lehetőséget mindenképp érdemes állandóan linkelni. Minek kell a régió? Használod valamire?
Session: az óvodás hacker is elsőre ezt a sütit keresi pl xss attack során. És nem szerencsés az md5 hash sem ma már.
azt is érdemes szem előtt tartani, hogy másik op rendszeren vagy böngészőn már ne működjön ugyanaz a session. Ha mégis vhogy el lopják vki sütijét, akkor ne legyen túl egyszerű felhasználni.
Egy valamirevaló felhasználó kezelés nem használ "gyári" php session t, hanem saját egyedit.
Szerk.: a session nem jó törölni, ha logout van, csomó értékes információ elvész, pl a nyelvi beállítás is. Csak azokat az adatokat töröld, amik user logged in miatt fontosak.
amúgy süti login van? Azzal nagyon vigyázni kell, ne tudja hacker ellopni, felhasználni.
Session: az óvodás hacker is
httpOnlysütemény, és akkor mindegy, hogy nevezed.macska - egér
Mondjuk én védekezni szoktam, de pandúrból lesz a legjobb rabló.
(Xss nem kizárólag JavaScript)
Xss nem kizárólag
<img src="valami_php_script.jpg />
<img src="valami_php_script.jpg />Persze kiszolgáló beállítva, hogy jpg-n is fusson PHP interpreter.
Miután kilolvastam a sütiket, matekoltam vele, amit akartam, adok neked egy jpg képet is, hogy azt hidd, nem történt semmi.
XSS nem kizárólag client-side scripts. Fenti megoldással legalább ugyanannyira "átszkripteltem" egyik site-ról a másikra.
Szerk.: csak ezt az img taget kell elhelyeznem a célpont oldalon, pl. ha engedi a html commentet, már jó is...
Péter, ha nem vagy biztos egy
A sütik domainhez kötöttek.
ennél részletesebben?
nem is mondtam olyat, hogy másik domain sütijét vizsgáljuk.
Egy nagyon egyszerű és régi dolgot írtam le, ezek szerint számodra nem elég érthetően. Nem szeretném jobban részletezni, mert nem kedvcsináló akartam lenni ebben a témában.
nem is mondtam olyat, hogy
Tényleg nem, de ez az egyetlen olyan kontextusa az általad írtaknak, amiben azok egy támadásként értelmezhetők. Ha a szkript a céldomainen fut, akkor mi értelme képnek álcázni?
Attól tartok,
Bő 5-6 éve olvastam erről egy cikket, azóta az az egy biztos, hogy "nagyon nem szeretem" az idegen url ről származó képeket.
Sajnos ezt a cikket telón nem találom. :(
Szerk. Szerintem mi is igen off ba mentünk.
Most mégis „idegen URL”-t
Köszi a választ, sokat
Javítom a hibákat.