ugrás a tartalomhoz

AngularJS v. Jquery

simisoma · 2015. Okt. 12. (H), 15.14
Sziasztok,

hogyan tudnám megoldani, hogy autómatikusan számoljon értéket és végösszeget:

<table>
     <tr>
           <td><input type='number' value='10' ng-model='mennyiseg' name='mennyiseg'></td>
           <td><input type='number' value='200' ng-model='egysegar' name='egysegar' ></td>
           <td>{{mennyiseg*egysegar}}</td>
      </tr>
      <tr>
           <td><input type='number' value='10' ng-model='mennyiseg' name='mennyiseg'></td>
           <td><input type='number' value='200' ng-model='egysegar' name='egysegar' ></td>
           <td>{{mennyiseg*egysegar}}</td>
      </tr>
      <tr>
           <td>Végösszeg</td>
           <td>{{teljes_vegosszeg}}</td>
      </tr>
</table>
‹ HTML iframe tag és a külső fájlok onchange this.form.submit() ›
 ■
1

Dokumentáció

Hidvégi Gábor · 2015. Okt. 12. (H), 16.16
A dokumentációból mit sikerült kiderítened? Mi az, ami nem működik?
2

Valami ilyesmi lesz, bár nincs benne jQuery és Angular

asam9 · 2015. Okt. 13. (K), 08.10
<table id="price-table">
    <tr class="item">
        <td>
            <input type="number" value="10" class="mennyiseg" name="mennyiseg">
        </td>
        <td>
            <input type="number" value="200" class="egysegar" name="egysegar">
        </td>
        <td>{{mennyiseg*egysegar}}</td>
    </tr>
    <tr class="item">
        <td>
            <input type="number" value="10" class="mennyiseg" name="mennyiseg">
        </td>
        <td>
            <input type="number" value="200" class="egysegar" name="egysegar">
        </td>
        <td>{{mennyiseg*egysegar}}</td>
    </tr>
    <tr>
        <td>Végösszeg</td>
        <td>{{teljes_vegosszeg}}</td>
    </tr>
</table>
var getTotalPrice = function () {

    var table, rows, price, quantity, total, len, i;

    table = window.document.getElementById('price-table');
    rows = table.querySelectorAll('tr.item');
    len = rows.length;
    total = 0;
    i = 0;
    
    for (; i < len; i++) {
        price = window.parseInt(rows[i].querySelector('.egysegar').value, 10);
        quantity = window.parseInt(rows[i].querySelector('.mennyiseg').value, 10);
        total += (price * quantity);
    }
    
    return total;
};

console.log(getTotalPrice());
3

minek?!

janoo · 2015. Okt. 15. (Cs), 08.06
nézegettem már én is ezt az AngularJs-t, javarészt álláshirdetésekben láttam, oszt gondoltam ránézek, hogy ez meg mi a fene

nade mi a fa**om értelme van ennek?!

azért húzzál be egy több száz-ezer soros (nem tudom mekkora) js fájt, hogy megcsinálja azt, amit egyébként 5 sorral meg tudsz oldani?!

Szóval el tudja valaki regélni, hogy a balfasz programozókon kívül, akik tök hüjék az egészhez, mi a francra jó ez az AngularJs?
4

Először is megkérlek, hogy

Hidvégi Gábor · 2015. Okt. 15. (Cs), 08.51
Először is megkérlek, hogy ezt az alpári nyelvezetet hagyd meg más fórumokra, itt nem szokás.

Az Angular azt a divathullámot lovagolja meg, hogy oldjunk meg mindent kliensoldalon Javascripttel. Szerintem eleve halott ötlet, hisz köztudott, hogy a kliens megbízhatatlan, egy csomó szerveroldali erőforráshoz nem is fér hozzá, valamint nem tudjuk, mi a kapacitása.
6

nézzünk már mögé egy kicsit

szabo.b.gabor · 2015. Okt. 15. (Cs), 09.48
egy csomó szerver oldali erőforráshoz nem is fér hozzá

minden böngésző, bármit is jelenítsen meg, csak azokhoz a szerver oldali erőforrásokhoz fér hozzá (jó esetben :D) amihez engedélyt adsz

a kliens megbízhatatlan

-ehhez mi köze az angularjs-nek?
-vagy arra gondolsz, hogy nem ugyanúgy fut le minden kliensen a kód? ez vicc.

valamint nem tudjuk, mi a kapacitása

akkor gondolkodjunk el valamin..
adatforgalom, html előállítás, oldal renderelés, válaszidő

adatforgalom
van egy listám, x rekord, végeredmény gyanánt minden rekordot feldiszítek némi html-lel. mi az optimálisabb? elküldeni az adatokat, és az egy elem létrehozásához szükséges statikus html template-et, vagy elküldeni az egész legenerált html-t? és ez még csak az első kérés volt, jó amit itt nyerünk, tegyük fel, hogy elvesztjük a plusz javascript kóddal, de kb egálban vagyunk. az összes többi kérés esetén (normális cache beállításokkal) már csak a csupasz adat utazik. hoppá. az adatforgalom a legdrágább összetevő és nem csak pénzben, de akksiidőben is.

html előállítás
ne terheljük vele a kliens-t. tényleg olyan drágák és bonyolultak a string műveletek? ne már.. nem ebben fog megkotlani a kliens, az már fájhat ha nagyon nagyra nő a DOM, de az nem az angular miatt van, hanem a hibás felépítés miatt, szerver oldalon is ugyanúgy létrejönne ugyanaz a kaki.

szóval angular esetén nyer a kliens az adatforgalmon (a szerver is!) amit itt nyer annak egy részét fel kell használni kliens oldali string műveletek végrehajtására. és itt is nyer a szerver is, hiszen csak statikus oldalakat kell kiszolgálnia, ha kell, valamint csak az adatlekéréssel kell bajlódnia. ha a szerver nyer, akkor szintén nyer a kliens is a gyorsabb válaszidők révén.

oldal renderelés
ha már előállt a html forrás akkor nincs különbség, ugyanannyi idő lerenderelni a dolgokat, ja várj, ha mondjuk lapozok a listában, akkor a körítéssel már nem is kell bajlódni angular (tágabb értelemben ajax) esetén, bakker már megint nyertünk itt is.. nem beszélve olyan esetekről amikor csak egy hibaüzenetet kell megjeleníteni, ezt is ketté választhatjuk olyanokra, amikhez nem kell valós adatellenőrzés (kötelező megadni), nem érv, hogy szerver oldalon úgyis ellenőrizni kell, most arról beszélünk amit a felhasználó lát, és hogy az mennyibe kerül. de lehetnek komolyabb ellenőrzések is (e-mail cím egyedi-e a rendszerben), ezt is olcsóbb "ajax"-szal megvalósítani a bonyolultság elfedésére van az angular.

válaszidő
folyamatos teljes oldallekérések vs részfeladatok végrehajtása akár a szerver beavatkozása nélkül.

nos engem meggyőzött, hogy az angular nem egy felesleges túlhájpolt divathullám. valós problémákra ad valós válaszokat, hogy ezek a válaszok jók-e vagy sem eldöntheti az idő, nekem bejön, egyszerűbb dolgozni vele, mint nélküle, tanulni meg úgyis kell.
8

+1 dolog

vbence · 2015. Okt. 15. (Cs), 10.15
A látogatók számának növekedésével egyenes arányban nő a kliensoldali erőforrás is (vagyis amit a kliens oldalon csinálunk abból nem lesz bottleneck peakek esetén).
9

Már többször kifejtettem,

Hidvégi Gábor · 2015. Okt. 15. (Cs), 10.50
Már többször kifejtettem, abban hiszek, hogy a kliensnek adatokat kell kiküldeni, azt, hogy azokkal mit kezd, legyen az ő dolga. Számomra a HTML zsákutca (amit a szerverről küldünk), a kliensoldali renderelésben hiszek, aminek két vége lehet, az egyik az Angular, a másik pedig az, ahogy én dolgozom.

Angular

Javíts ki, ha tévedek, de az Angularban általában minden logika a kliensoldalon van, az üzleti objektumok a böngésző memóriájában csücsülnek, és adatmanipulálási hívásokat kezdeményeznek a szerver felé.

Mivel a kliens nem megbízható, ezért minden bejövő adatot a szerveren is le kell ellenőrizni, azaz az üzleti logika egy része mindkét helyen megvan, ami mindenképp bonyolítja a programot, még akkor is, ha a szerveren ugyancsak JS van, hisz bizonyos ellenőrzéseket csak a szerveren lehet elintézni (pl. van-e már az adatbázisban ilyen e-mail cím).

Ha kliens- és szerveroldalon is JS van, az segíthet, de ekkor a két kód coupled, egymáshoz van kötve. Ha jön egy újabb divathullám, feltalálják az új Nyelvet, ami ezerszer gyorsabb a JS-nél, akkor máris hátrányban vagy.

Ha kliensoldalon van az üzleti logika (egy része), akkor a klienst terheled, amiről nem tudod, hogy mennyi erőforrással rendelkezik, lásd az aktuális blogmarkot, ráadásul minden JS objektum jóval több memóriát és processzoridőt igényel, mint a natív, szóval minél több van a kliensen, annál nagyobb az esély, hogy a felhasználók egy része nem fogja tudni használni a programodat.

"Vékony" kliens

Ezzel szemben én abban hiszek, hogy küldjük ki az adatokat, adjunk mankót a kliensnek a rendereléshez, de minden üzleti logika legyen a szerveren.
  • kevesebb munka, kevesebb hibázási lehetőség
  • húszéves böngészőn is elfut a program
  • nem csak böngészővel lehet az adatokat elérni, hanem bármilyen más klienssel, például mobil alkalmazással, speciális keresővel, bármivel
  • a szerveroldalt bármikor lecserélhetem
Egy ilyen vékonykliens is lehet JS-ben írva, de ennél szerintem jobb az XSLT, egy bizonyos szint felett pedig az XSLT + kis JS.
10

Javíts ki, ha tévedek, de az

szabo.b.gabor · 2015. Okt. 15. (Cs), 12.51
Javíts ki, ha tévedek, de az Angularban általában minden logika a kliensoldalon van


természetesen nem, az üzleti logika nyilván szerver oldalon van, de ez mondjuk kb egy rest jellegű api, tehát mondjuk az elérhető funkciók gyűjteménye, azok paramétereivel, visszatérési értékeivel.

több dolog van kliens oldalon, de ezeknek nincs közük az üzleti logikához. pl routing, felület kialakítása, milyen esemény hatására milyen api hívás fusson le, ezután, mi történjen. szerintem gyönyörűen szétválasztható az üzleti logika és az azt használó felület kialakítása.

az angular 'objektumok' arra vannak, hogy a view és a model szinkronban legyenek, ne kelljen azzal foglalkozni (ami egyébként egy elég unalmas, de megterhelő feladat - változik egy adat, jelen van az oldalon 4 helyen és te csak 2nél frissíted mezítlábasan, függ ettől még három másik dolog szintén több helyen megjelenítve..).

validálás.. nem kell hogy ugyanaz a kód fusson itt is ott is, a lényeg hogy ugyanazt a konfigot használják. van 4-5 féle szabály amelyek dolgoznak néhány paraméterrel, ezekhez meg lehet írni az ellenőrző szkripeket mindkét oldalon, de ha ezek megvannak, akkor nem kell egy form megírásakor kétszer dolgozni.. ha újfajta szabályra van igény, akkor azt meg le lehet kódolni mindkét helyen..

olvastam én is AMP-ről. egyszerűen hülyeségnek tartom. akik nem értenek hozzá, ebben is fognak tudni olyan dolgokat készíteni, amik túl sok erőforrást használnak. és azt azért ne feledjük el, hogy ez a dolog statikus tartalmakhoz lett kialakítva, nem felhasználói felületekhez.

XSLT
kiváltja a html-t? nem
kiváltja a css-t? nem
kiváltja a js-t? nem
alkalmas az xml programozásra? átlátható? tömör? nem
rakjak hozzá egy 4. dolgot ami eleve alkalmatlan bármilyen feladatra? bonyolítsam még tovább? szerintem nem kéne.

jó és szép dolog az xml, de nem hiába terjed el a json pl. programozásban is inkább az egyszerű dolgokat jó használni lásd javascript vs coffescript. mondjuk nekem nem elég kusza a js ahhoz, hogy coffescript-re váltsak, de egy xslt.. nem embernek való.
<xsl:if test="../hibauzenet/@id = 'jelszo'">
  <xsl:attribute name="class">urlap_sor hiba</xsl:attribute>
</xsl:if>
11

az angular 'objektumok' arra

Hidvégi Gábor · 2015. Okt. 15. (Cs), 13.19
az angular 'objektumok' arra vannak, hogy a view és a model szinkronban legyenek, ne kelljen azzal foglalkozni (ami egyébként egy elég unalmas, de megterhelő feladat - változik egy adat, jelen van az oldalon 4 helyen és te csak 2nél frissíted mezítlábasan, függ ettől még három másik dolog szintén több helyen megjelenítve..)
Nekünk ezt sikerült szerveroldalon megoldani – akkor minek terheljük vele a klienst?

több dolog van kliens oldalon, de ezeknek nincs közük az üzleti logikához. pl routing, felület kialakítása, milyen esemény hatására milyen api hívás fusson le, ezután, mi történjen. szerintem gyönyörűen szétválasztható az üzleti logika és az azt használó felület kialakítása
Lehet, hogy te szét tudod választani, de a téma indítójának láthatóan nem sikerült, magyarul nem egyértelmű a dolog.
12

Nekünk ezt sikerült

szabo.b.gabor · 2015. Okt. 15. (Cs), 13.29
Nekünk ezt sikerült szerveroldalon megoldani – akkor minek terheljük vele a klienst?

pont azzal terheled a klienst, hogy felesleges http kérést hajtasz végre (lásd a 6-os hozzászólást). nem a kliens-t kíméled, pusztán magadat, ráadásul ennek komoly ára is van.

Lehet, hogy te szét tudod választani, de a téma indítójának láthatóan nem sikerült, magyarul nem egyértelmű a dolog.

én nem is a téma indítójára reagáltam, hanem arra a részre, hogy
Az Angular azt a divathullámot lovagolja meg, hogy oldjunk meg mindent kliensoldalon Javascripttel. Szerintem eleve halott ötlet, hisz köztudott, hogy a kliens megbízhatatlan, egy csomó szerveroldali erőforráshoz nem is fér hozzá, valamint nem tudjuk, mi a kapacitása.
13

pont azzal terheled a

Hidvégi Gábor · 2015. Okt. 15. (Cs), 13.50
pont azzal terheled a klienst, hogy felesleges http kérést hajtasz végre
Nem terhelem a klienst egyáltalán. Amikor megváltoztatom egy mező értékét, a szerver meghatározza, hogy melyek a kapcsolódó űrlapok, és mindegyiknek beolvassa az adatait, és erre az egy kérésre kiküldi válaszként. Ezzel biztosítjuk, hogy tényleg minden frissüljön.

Ennek a logikának az Angularban is meg kell lennie, csak ugye kliensoldalon. Viszont ha valamilyen oknál fogva lecserélnétek a klienst, például átírnátok mobilalkalmazásra, akkor ott is meg kéne valósítani a kliensen belül az összefüggések kezelését.

Nálunk ezeket a szerver kezeli, így sokkal portolhatóbb a rendszer, ráadásul jóval könnyebben lehet rajta változtatni, hisz minden adatmanipuláció a szerveren történik, a kliens csak megjeleníti bután azt, amit kap.
14

az előző hozzászólásban

szabo.b.gabor · 2015. Okt. 15. (Cs), 14.24
az előző hozzászólásban próbáltam körülírni a terhelés fogalmát, mondjuk akkuidőre (processzor, rádiós modulok), felhasználói élményre (válaszidő..), bónuszként szerveridőre levetítve.

portolhatóságról nem volt szó eddig. olyan szempontból tényleg érdemes lehet egy kézben tartani a dolgokat. ez üzleti döntés, és plusz absztrakciós réteget igényel :D, ráadásul egyáltalán nem biztos, hogy egy monitorra kifejlesztett felület, workflow portolható mobilra.. szerintem a kliensen belüli összefüggések a klienstől kell, hogy függjenek, jobb azokat nem központosítani.

aztán beszélhetünk még sok mindenről, de ez már túlmutat az angular feleslegességéről szóló vitán.
15

Mivel a kliensoldal

Hidvégi Gábor · 2015. Okt. 15. (Cs), 15.00
Mivel a kliensoldal paramétereit nem tudod befolyásolni, nem tudhatod, hogy egy 1 vagy 4 GHz-es processzoron fut, azon belül mondjuk X86 vagy ARM vagy MIPS architektúrán, márpedig nem 1:1 a váltószám a hertzeknél a sebességre.

A munka mind vastag- (Angular) mind vékonykliens esetében ugyanannyi, de ha szerveren végzed el, ott a te kezedben van minden, azaz lecserélheted a vasat, ha lassú. Ha egy 1 GHz-es ARMv7-en fut a rendszered, lehet több akkut eszik egy kliensoldali logika (feladattól függően az Angular egy egész bonyolult objektumstruktúrát kell a memóriában tartson, hogy tudja, egyik adat megváltozásakor a képernyőn mit kell még frissíteni), mintha csak annyi lenne a dolga, hogy írja át a megfelelő mezők értékét.

Az meg nagyjából mindegy, hogy 100 vagy 300 bájt adatot küldesz a neten, nem lehet észrevenni.
16

Lehet :)

szabo.b.gabor · 2015. Okt. 15. (Cs), 15.07
Lehet :)
17

Bizony : )

Hidvégi Gábor · 2015. Okt. 15. (Cs), 15.34
Bizony : )
5

ebben a fórumtémában épp

szabo.b.gabor · 2015. Okt. 15. (Cs), 08.56
ebben a fórumtémában épp nincs egy sornyi angular kód sem írva :)

amúgy nagyon jó cucc szerintem. nézd meg a hivatalos tutorial-t első körben, ha tényleg érdekel.

ha mélyebben is érdekel a dolog, akkor johnpapa-nak vannak nagyon jó dolgai a githubon.
7

Majd egyszer megérted, most

bamegakapa · 2015. Okt. 15. (Cs), 09.58
Majd egyszer megérted, most még hiába erőlködnénk.
18

Nem 5 soros projektekhez

inf · 2015. Okt. 16. (P), 04.31
Nem 5 soros projektekhez találták ki az angular-t.

Szívem szerint törölném ezt a hozzászólást. Az egész szövege ócska, az alatta lévő flamewar-nak meg semmi értelme.
19

+1

vbence · 2015. Okt. 18. (V), 15.48
+1 - apropó tervbe van véve a közösségi moderáció?
20

Gondoltam, ha már ennyi időt

inf · 2015. Okt. 18. (V), 17.20
Gondoltam, ha már ennyi időt belefektettek a hozzászólók a mondandójuk leírásába, akkor jobb hagyni. Nem tudom, hogy Ádám mit fejleszt bele éppen az oldalba, őt kellene megkérdezni.
21

Gondoltam, ha már ennyi időt

Joó Ádám · 2015. Okt. 22. (Cs), 01.25
Gondoltam, ha már ennyi időt belefektettek a hozzászólók a mondandójuk leírásába, akkor jobb hagyni.


Általában a legsilányabb témafelvetések is értékes hozzászólásokat generálnak, ezért is az az alapelv, hogy csak a legszükségesebb esetben törlünk.
22

Pluszozás lesz, az értéktelen

Joó Ádám · 2015. Okt. 22. (Cs), 01.30
Pluszozás lesz, az értéktelen hozzászólások így egyrészt egy pillantással kiszűrhetők majd, illetve a végére rendezhetők. Ezen kívül lehet majd flagelni a problémás kommenteket, amik sorsáról a jövőben is a moderátorok döntenek majd (akik körét, ha vállalják, szívesen bővíteném a közösség további megbízható tagjaival).

De: lásd a válaszom inf3rnonak.
23

Ez így szerintem tök jó lesz.

inf · 2015. Okt. 22. (Cs), 09.07
Ez így szerintem tök jó lesz. Lehetne pl olyat, hogy a sok mínuszt gyűjtött commentek becsukódnak, és kinyithatja őket az, akit érdekel. Láttam már ilyet 1-2 oldalon. Így megmaradhatna a teljes comment fa úgy is, hogy a problémás commenteket elrejtjük és csak a rájuk adott használható válaszokat mutatjuk csak.
24

Sok értelmét nem látom az

Hidvégi Gábor · 2015. Okt. 22. (Cs), 11.11
Sok értelmét nem látom az elrejtésnek, hisz ez egyrészt cenzúra, másrészt sosem tudhatod, milyen valós érték van mögötte. Ha például a középkorban is lettek volna fórumok, ott is ugyanígy eltüntették volna a Föld kerekségére utaló felfedezéseket - hol tartanánk ma, ha így lett volna?

De ha mindenképp eltüntetnétek ezeket, akkor inkább javascripttel, mint css segítségével, hisz az előbbit ki lehet kapcsolni, az utóbbit nem.
25

Voltak

vbence · 2015. Okt. 22. (Cs), 11.40
A középkorban is voltak fórumok, de akkor leszúrták aki a föld kerekségéről beszélt; vagy máglyára küldték (olyankor előtte azért megadták a lehetőséget, hogy visszavonja tanait).

Szerintem amúgy nincs szó elrejtésről.

De nagyon offtopic kezdünk tévedni.
26

Én nyugodt szívvel beáldozom

bamegakapa · 2015. Okt. 22. (Cs), 12.06
Én nyugodt szívvel beáldozom a 99% tömény baromságot, még ha közben talán el is veszik 1% értelem. Az ember könnyen Galileinek képzeli magát, de én itt, senki ne vegye sértésnek, még eggyel sem találkoztam.

hol tartanánk ma, ha így lett volna?

Itt tartunk, mivel így volt, ahogy vbence vázolta.
27

Jézust sem ismerték

Hidvégi Gábor · 2015. Okt. 22. (Cs), 12.23
Jézust sem ismerték fel/értették meg a kortársai.
28

Bizony

vbence · 2015. Okt. 22. (Cs), 12.31
Bizony mondom nektek, hogy egy prófétát sem látnak szívesen a saját hazájában.
29

Ez így van. És attól sem

bamegakapa · 2015. Okt. 22. (Cs), 13.13
Ez így van. És attól sem fogják felismerni/megérteni, ha az arcukba toljuk, elkeverve több ezer holdkórós agyszüleményei közé.

A szemétgyűjtést sem szüntetjük be csak azért, mert nagy ritkán értékes kincsek kerülnek valami szörnyű hiba folytán a szemétbe. Attól a többi, ami tényleg szemét, ott fog bűzölögni az utcán.
32

Az, hogy kinek mi a szemét,

Hidvégi Gábor · 2015. Okt. 22. (Cs), 13.49
Az, hogy kinek mi a szemét, mindenki hadd döntse el maga.
34

Pont erre lenne jó a mínusz.

bamegakapa · 2015. Okt. 22. (Cs), 14.09
Pont erre lenne jó a mínusz.
36

A mínusz nem hordoz

Joó Ádám · 2015. Okt. 22. (Cs), 19.41
A mínusz nem hordoz elég információt. Ha nem értesz egyet valamivel, akkor indokold. Ha úgy gondolod, hogy egy megnyilvánulásnak nincsen helye a fórumon, akkor meg kérd a törlését.

A pluszozás lehetővé teszi, hogy az olvasó felmérje, egy-egy megszólalás mögött mekkora a közösségi konszenzus, de nem diszkriminálja az alternatív nézőpontokat.

(Keserűek a tapasztalataim például a Server Faulton, ahol ugyan a nyilacskán a felirat, hogy „This question does not show any research effort; it is unclear or not useful”, de az a divat, hogy a kérdés összeszedettségétől függetlenül leverik rólad az összes karmát, csak mert olyan megoldást keresel, ami az esetek nagyobb részében nem tekinthető jó gyakorlatnak – függetlenül a konkrét körülményektől.)
37

Hát mínusz szempontjából az

inf · 2015. Okt. 22. (Cs), 20.40
Hát mínusz szempontjából az sto nagyon elfajult világ, jobb nem hozzá hasonlítani semmit.
40

Annyiból elfajult, hogy

bamegakapa · 2015. Okt. 22. (Cs), 23.55
Annyiból elfajult, hogy máshogy nem működik :). Amióta lazítottak a szabályokon, ott is túlcsordult már a szemét sajnos.

Értékes szakmai tartalmat csak akkor tudsz előállítani, ha van egy nagyon szigorú értékelési rendszered. Persze ez az itteni fórumon nem feltétlenül cél, de ott ez volt eredetileg. Nem az egyes kérdezőknek akartak egyénileg segíteni, hanem mindenkinek, aki hasonló probléma miatt megtalálta az adott kérdést (gondolom ezért pontozták le Ádám megoldását). Pont ezért mindig megtalálom ott a válaszokat, amiket keresek. És ha egy válasz nem elég jó, akkor osztom a mínuszt szemrebbenés nélkül :).
41

Nem az egyes kérdezőknek

Joó Ádám · 2015. Okt. 23. (P), 00.33
Nem az egyes kérdezőknek akartak egyénileg segíteni, hanem mindenkinek, aki hasonló probléma miatt megtalálta az adott kérdést (gondolom ezért pontozták le Ádám megoldását).


A kérdésemet pontozták le. Nem azért, mert nincs ott helye, mert formailag kivetnivalót hagy maga után, vagy mert nem kerestem volna előtte – hanem mert szerintük, amit csinálni akarok, az nem jó gyakorlat.

Ez márpedig – és itt, akár tetszik, akár nem, Gábornak igaza van – dogma és cenzúra.
42

Így látatlanban nem tudom

bamegakapa · 2015. Okt. 23. (P), 01.17
Így látatlanban nem tudom megítélni. Az SF kultúráját és szabályzatát kevéssé is ismerem.

Szakmai cenzúra szükséges, hogy ne villámgyorsan egy szemétdomb tetején találjuk magunkat, ahol mindenki a saját hülyeségét hirdeti. Ilyenkor néha hibák becsúsznak és kidobásra kerül olyan is, amit nem kellett volna. Ez korrigálható és bőven megéri, ha a rendszer jól van kidolgozva (mint például az SE).

A dogma nem értem, hogy jön ide. Ha valóban nem jó gyakorlat, amiről kérdezel, akkor a később jövőknek a lepontozás lehet hasznos jelzés. Attól még választ kaphatsz. Nekem is van lepontozott kérdésem, nincs azzal semmi baj.
43

A kérdés arra vonatkozott,

Joó Ádám · 2015. Okt. 23. (P), 02.24
A kérdés arra vonatkozott, hogyan tudom kikapcsolni az autentikációt az SSH démonban. Külön kiemeltem, hogy természetesen tisztában vagyok a biztonsági vonatkozásaival.

Szakmai cenzúra szükséges, hogy ne villámgyorsan egy szemétdomb tetején találjuk magunkat, ahol mindenki a saját hülyeségét hirdeti.


Azért elég nagy a mozgástér aközött, amivel nem értek egyet, meg ami hülyeség, szerintem ezt te sem gondolod másképp. Arról nem is beszélve, hogy a hülyeséget sem feltétlen érdemes cenzúrázni, mert így egy rossz kérdésre adott jó választ a következő kérdező is megtalál.

Ilyenkor néha hibák becsúsznak és kidobásra kerül olyan is, amit nem kellett volna.


A baj az, hogy ezek nem elszigetelt esetek, az egész SE nagyon súlyos problémákkal közd, és ezek a dolgok folyamatosan témák kérdések alatti kommentekben és a metákon is.

A dogma nem értem, hogy jön ide. Ha valóban nem jó gyakorlat, amiről kérdezel, akkor a később jövőknek a lepontozás lehet hasznos jelzés. Attól még választ kaphatsz. Nekem is van lepontozott kérdésem, nincs azzal semmi baj.


Az a baj vele, hogy egyszerűen nem ezt jelenti a mínusz. A lefele mutató nyilacskának ez a felirata: „This question does not show any research effort; it is unclear or not useful”. A negatív pontszám azt jelzi, hogy egy tartalom alacsony színvonalú, nem érdemes elolvasni. A pontszám a karmádra is kihatással van, ami azt jelzi, hogy mennyire vagy konstruktív tagja a közösségnek.

És itt jön a dogma: ha az egyet nem értés kifejezésére használják a pontrendszert, akkor azzal egyrészt beszűkítik a társalgást, másrészt a közösség vezetői is egyetlen körből fognak kikerülni, tovább erősítve ezt a hatást.

Összességében az SE szerintem nagyon jó példája annak, milyen gondokkal küzd a demokrácia mint intézmény a gyakorlatban.
45

Azt hiszem a lényegre

inf · 2015. Okt. 23. (P), 12.27
Azt hiszem a lényegre rávilágítottál. A többség el sem olvassa, hogy mit jelent a lefele nyíl. Nem tetszik, nem értem, mínusz, ennyi.
48

Megnéztem a kérdést. Nem

bamegakapa · 2015. Okt. 23. (P), 13.36
Megnéztem a kérdést. Nem vagyok ott járatos, de megértem, miért gondolják "not useful"-nak. A bezárás indoklását is logikusnak érzem.

Az SE szerintem is problémákkal küzd, de azért, mert egy időben beengedtek mindenkit. Ez a rakás ember elolvasni sem volt hajlandó a szabályokat, hát még megérteni, vagy magára érvényesnek tekinteni. Csak a saját dolguk érdekelte őket. Ilyen hozzáállású emberekkel a demokrácia nem működőképes.
50

Ezzel kapcsolatban hosszabban

Joó Ádám · 2015. Okt. 24. (Szo), 03.15
Ezzel kapcsolatban hosszabban írtam a Metára, talán érdekes lehet. Mindenesetre a véleményem fenntartom: sehol nem láttam még olyan mínuszozásra lehetőséget adó rendszert, amivel ne éltek volna vissza a felhasználók.
51

Nálad is megvan a meta

inf · 2015. Okt. 24. (Szo), 06.44
Nálad is megvan a meta életérzés -11 pont. Én is összehoztam már egy -10 pontos kérdést. :D

Az emberek általában mindennel visszaélnek, ha nincs szabályozva. Ha büntetést kapna valaki, mert ész nélkül osztja a mínuszokat, akkor más lenne a helyzet.
52

Továbbra is úgy érzem, a

bamegakapa · 2015. Okt. 24. (Szo), 19.09
Továbbra is úgy érzem, a mínuszokkal egy gond van, hogy nem használják elegen elégszer, nehogy megsértsenek valakit.
53

Szerintem a fő gond vele,

inf · 2015. Okt. 24. (Szo), 19.37
Szerintem a fő gond vele, hogy nem olyan rendszerű, mint a close. Ha nem írják meg, hogy mi a bajuk a hozzászólással, akkor nehéz javítani rajta.
54

Közelítsük meg a másik

Joó Ádám · 2015. Okt. 24. (Szo), 20.41
Közelítsük meg a másik oldalról: szerinted miért jó a mínusz?
56

Jelezhető, ha egy poszt nem

bamegakapa · 2015. Okt. 27. (K), 13.38
Jelezhető, ha egy poszt nem felel meg az adott oldal szakmai irányelveinek. Másképp nem lehet biztosítani, hogy egy adott színvonal hozva legyen, az irányelvekre mindenki tenni fog magasról.
57

Ezt az oldal moderátorai el

Hidvégi Gábor · 2015. Okt. 27. (K), 15.01
Ezt az oldal moderátorai el tudják dönteni. Mivel biztosítod, hogy az átlagos olvasó valóban a szakmai irányelvek szerint mínuszol, és nem pedig szubjektíve?
58

Az oldal moderátorai nem

bamegakapa · 2015. Okt. 27. (K), 15.17
Az oldal moderátorai nem érnek rá, kevesen vannak, elegük lesz a sok baromból, stb. Másrészt a feldühödőtt tömeg őket fogja támadni, amit elég gyorsan megunnak.

SO-n az egész egy pontrendszerre épül, és a mínusz alkalmazása a te pontjaidból is levon. Így puszta szórakozásból senki nem fogja használni, legalábbis a tapasztalat ezt mutatja. Ráadásul az oldal különböző funkciói pontszámhoz vannak kötve, új felhasználóként nem mínuszolhatsz, csak ha már valamit hozzátettél a közösséghez.

Belátom ugyanakkor, hogy itt a Weblaboron nem időszerű a mínusz (vagy akár a plusz) használata, mert nem képződik tartalom, amit szűrni kéne.
60

Belátom ugyanakkor, hogy itt

Joó Ádám · 2015. Okt. 28. (Sze), 02.28
Belátom ugyanakkor, hogy itt a Weblaboron nem időszerű a mínusz (vagy akár a plusz) használata, mert nem képződik tartalom, amit szűrni kéne.


Érzem én ebben a gúnyt, de azért csak reagálok az érdemi részére: szerintem a plusz nagyban ösztönözheti a hozzájárulást (sok más mellett).
59

Honnan fogja tudni az olvasó,

Joó Ádám · 2015. Okt. 28. (Sze), 02.25
Honnan fogja tudni az olvasó, hogy mi a probléma a poszttal? Honnan fogja tudni a szerző, hogy mi a probléma a poszttal?

Ha a posztok szerzői tesznek az irányelvekre, akkor miért gondolod, hogy a pontozók majd tartják magukat hozzájuk?

Ha az oldalnak szakmai irányelvei vannak, amelyek alapján egyértelműen eldönthető, hogy egy-egy javaslat megfelelő-e, akkor mennyiben van létjogosultsága még bármilyen társalgásnak?
61

1. Vagy elolvassa a

bamegakapa · 2015. Okt. 28. (Sze), 10.08
1. Vagy elolvassa a szabályzatot hogy megértse (ez remek), vagy mérgesen lelép (ez is remek).

2. Onnantól, hogy neked kerül valamibe a mínusz, nem fogod össze-vissza osztogatni. Persze lesznek kivételek, de egy egyensúly beáll. Legtöbb esetben ha nem ismered a szabályzatot, nem jutsz annyi ponthoz, hogy tudj mínuszolni.

3. Ezt nem értem.
62

Gondolom arra gondol, hogy ez

inf · 2015. Okt. 28. (Sze), 16.02
Gondolom arra gondol, hogy ez nem egy q&a oldal, hanem egy fórum, szóval ha offtopic társalgunk, mint most, akkor kaphatunk egy rakás mínuszt...
63

Az oké, de akkor a plusznak

bamegakapa · 2015. Okt. 28. (Sze), 16.12
Az oké, de akkor a plusznak sincs sok értelme :).
64

Talán ha olyanok az

inf · 2015. Okt. 28. (Sze), 16.30
Talán ha olyanok az irányelvek, hogy nem q&a alapúra vesszük a figurát, hanem megengedett az offtopic társalgás. A flaggelésnek szerintem több értelme lenne, csak hogy valami mást vegyek elő q&a oldalakról. A felhasználó megflaggeli, hogy nem tetszik neki egy bot vagy egy troll hozzászólása, aztán az admin foglalkozik vele. Ha túl sok téves flaget kapunk valakitől sorozatban, akkor attól megvonják a flaggelés jogát. Itt is lehetne egy pontrendszert csinálni, hogy ki mennyi pozitív és negatív flaget gyűjtött, aztán az alapján esetleg akár admin jogot is adni. A mostani rendszerbe is illik valamennyire, a mostani adminok kaphatnának x pontot induláskor.

A q&a pontozós része a dolognak mehetne úgy, hogy jelölni kell fórum téma nyitásnál, hogy kérdésről van szó, és jelölni kell a hozzászólásnál, hogy a kérdésre adott válaszról van szó. Így pontot csak ezek a hozzászólások kapnának, a maradékot meg nem lehetne pontozni. Úgyanúgy lehetne flaggelni, ha valaki hibásan nyomta rá a checkbox-ot, és nem választ adott, hanem csak hozzászólt a témához. Ha túl sok ilyet csinál, akkor meg meg lehet vonni tőle a jogot, hogy választ adjon vagy kérdést tegyen fel.

A bot flaggelésnél még érdemes lenne valamit kitalálni, hogy automatizálni lehessen. Ugye az a gond, hogyha valaki kap mondjuk 10 bot flaget, és eldobjuk az összes hozzászólását, meg letiltjuk az accountját, akkor bárki megcsinálhatja azt, hogy létrehoz egy botot, ami regisztrál 10 felhasználót, és mindegyik ad egy-egy bot flaget. Vagy a flag osztást kell valami aktivitáshoz, pl pont gyűjtéshez kötni, vagy minden ilyen esetre az automatikus letiltás mellett rá kell állítani egy admint, hogy vizsgálja felül, hogy tényleg jogos volt-e. Ami még fontos lehet, hogyha valakinek lenyúlják az accát, és arról megy a bot, akkor ne vesszen el az összes addigi hozzászólása. Bár ez a ritkább, de mindenképp lehetséges. Szóval az admin opcióba bele lehetne rakni hasonlóan a q&a review-hoz, hogy real bot / account taken / skip vagy valami hasonlót.
65

Ilyen szempontból nem sok

bamegakapa · 2015. Okt. 28. (Sze), 16.54
Ilyen szempontból nem sok különbséget látok a mínusz és a fleggelés között, mindkettő a lefektetett irányelveknek való megfelelést értékeli (irányelvek híján az admin önkénye döntene). Tehát az ötleted tetszik :).
68

Annyi a különbség, hogy a

inf · 2015. Okt. 28. (Sze), 17.24
Annyi a különbség, hogy a flag-nél hozzá kell tenni, hogy mi miatt nem felel meg az irányelveknek. Így ha valaki nincs tisztában az irányelvekkel, akkor vagy nem tud választani a listáról, vagy valami random dologra rábök, amire meg az admin azt mondja, hogy hibásan értékelt, és ezért nem fogadja el a flag-et, ami esetleg mínusz ponttal járhat az ő részére, és túl sok mínusz ponttal nem tud majd flaggelni mondjuk egy hónapig. Így lehetne biztosítani, hogy az irányelveknek megfeleljen a moderáció, és ne csak random szórjuk a mínuszokat.
66

Amennyire tudom

vbence · 2015. Okt. 28. (Sze), 16.57
Amennyire tudom, itt mindig az volt a szabály, hogy új kérdés = új téma. Általában az offolás öli meg a legtöbb értelmes társalgást (pl amikor amikor elkezdünk az energia előállításáról beszélni).

A közösség döntse el, hogy meddig tűri meg az offolást. Itt pl nem hiszem, hogy sokan lepontoznának ezért a szálért, ha meg igen, megunkba nézünk és új témát nyitunk neki.
67

Szerintem az offolás

inf · 2015. Okt. 28. (Sze), 17.20
Szerintem az offolás lehetősége olyan szabadságot ad, ami egy q&a oldalon nincs meg, és nem tartanám jónak ha ez elveszne a túl szigorú moderáció miatt, a végén prog.hu-vá fajulna a fórum, ahol ha bármit hozzá mersz szólni, akkor 10 troll ugrik rád a bózótból (volt már rá példa). Szóval az offolás miatti mínuszozást én nem támogatom.

A szálak külön témába helyezése sem oldja meg a problémát, van, hogy elkanyarodik a beszélgetés a témáról, aztán meg visszakanyarodik rá, szóval nem lehet egyértelműen kivágni azt a részt és új témába tenni, nem lehet így modellezni a problémát. Lehetne esetleg off-topic checkbox-ot vagy kódszínezőt betenni. Ez többé-kevésbé működik, de nem mindenki veszi komolyan, erre admin energiát fordítani meg szerintem pazarlás.
44

Hát nekem az a benyomásom,

inf · 2015. Okt. 23. (P), 12.24
Hát nekem az a benyomásom, hogy van aki írt egy botot, ami minden új kérdésre random osztja a mínuszt. Utána meg ha már egy rajta van, akkor a többit összerakják a többiek. Válasznál is kaptam már 3 mínuszt a jó válaszra, csak mert nem tetszett, hogy RTFM-et írtam egy fokkal finomabb megfogalmazásban. Még idéztem is a standard megfelelő részeit. És hát mégsem, nem szabad szabványra hivatkozni, mert azt senki nem olvassa, értelmezni meg még annyival kevesebben tudják. Kérdéseknél még én kérek elnézést másoktól, hogy a sok barom leszavazta a teljesen értelmes kérdésüket. Körülbelül ez a szint az so kb az esetek 20-25%-ában. Egyébként rendben van. Végülis a használható tartalom 3/4-e megmarad, az meg talán nem vészes.
47

Megnéztem az adott választ,

bamegakapa · 2015. Okt. 23. (P), 13.15
Megnéztem az adott választ, szerintem csak annyit hiányoltak, hogy kicsit kifejtsd/megmagyarázd azon túl, hogy ez az egyben idézed a szabványt. Ami remek, csak mint te is mondod, kevesen tudják értelmezni :). A cél, hogy a később jövők választ kapjanak.

Megszámolni sem tudom, hány mínuszt kaptam már, a nagy részét vissza is vonták, miután javítottam a válaszomon. Utólag hideg fejjel visszanézve a válaszom tényleg hasznosabb lett. A mínuszok szerintem, ha az egót kiiktatom egy időre, baromi hasznosak.

Ami a kérdéseket illeti, szerintem még így sem elég a szigor. Szinte senki nem olvassa el a kérdésekre vonatkozó szabályokat, mielőtt kérdezne, pedig ezek nem hasraütésre kitalált szabályok, hanem éveken keresztül lettek kidolgozva a tapasztalatok alapján.
49

Ebben nagyon egyetértünk. Én

inf · 2015. Okt. 23. (P), 18.28
Ebben nagyon egyetértünk. Én csak a hydra-t követem többé kevésbé, az RDF-es szabvány REST vocab (lesz), de azon is már évek óta megy a huza-vona, hogy ezt így vagy úgy csináljuk. Kb. ez a sosem lesz kész életérzése van.

Lehet, hogy javítana, ha hozzáírnék még magyarázatot, de nincs kedvem hozzá. Ja quote-okat amúgy sem szeretik válasznak elfogadni más exchange-es fórumon sem. Amivel nekem comment-be indokolták, hogy hát látszik a kérdésen a research effort, és ezért nem lehet egy RTFM-el elintézni. Én nem láttam rajta. :-) Mármint csak annyit láttam rajta, hogy keresgélt példa API-kat, de a szabványba nem volt hajlandó beleolvasni. REST meg hát szabványokra épül, tetszik, vagy sem. Nehéz olyan példát mutatni, ami mindenben megfelel REST-nek meg szabványoknak is, mert mindenki csak a másikat próbálja majmolni, ahelyett, hogy rászánná az időt, és utánaolvasna. Valahol megértem, mert én is 1 évig ezt csináltam, és utána esett le, hogy nem vezet sehova, mert nem olyan a téma, amit gyakorlati úton meg lehetne tanulni zéró elméleti tudással.
30

Mínusz nincs tervben. Sehol

Joó Ádám · 2015. Okt. 22. (Cs), 13.23
Mínusz nincs tervben. Sehol sem működik.
31

Én annyira a plusz egyezésben

Hidvégi Gábor · 2015. Okt. 22. (Cs), 13.48
Én annyira a plusz egyezésben és a lájkolásban sem hiszek, mert olyan személytelen, nem tudhatjuk, hogy nem az illető személyének szól-e, és amúgy is egyre kevesebbet beszélünk. Ha valami tetszik, akkor azt odaírom, és azt is, hogy miért.
33

Nekem pedig kimondottan

kuka · 2015. Okt. 22. (Cs), 13.57
Nekem pedig kimondottan tetszik amikor a StackExchange oldalakon rászólnak a szófosókra, hogy tetszést az upvote-tal kell nyilvánítani, nem hozzászólással. (Jó, tudom, az nem fórum. Viszont nagyon hatékonyak a szemétfelhalmozódás megelőzésében.)
35

A „+1” és „szerintem is”

Joó Ádám · 2015. Okt. 22. (Cs), 19.20
A „+1” és „szerintem is” típusú hozzászólások nem hordoznak sok információt, csak zajt adnak a beszélgetéshez, illetve ezek mentén nem lehet kiemelni az értékes megnyilvánulásokat. Arról nem is beszélve, hogy ha egy kattintással adhatsz visszajelzést, akkor várhatóan sokkal több ember fog adni, mintha hozzászólást kell fogalmazni úgy, hogy a lehető legkevesebbet ismételd az előtted szólókat.
38

Hmm és ahhoz mit szólnál, ha

inf · 2015. Okt. 22. (Cs), 20.42
Hmm és ahhoz mit szólnál, ha a plusszosokat emelnénk ki. Pl szürkéről indulna a hozzászólás, és minél több pluszpont lenne rajta, annál jobban beszínesedne, vagy ilyesmi.
39

Gondoltam rá, hogy vizuálisan

Joó Ádám · 2015. Okt. 22. (Cs), 21.14
Gondoltam rá, hogy vizuálisan ki lehetne emelni, de nem tudom, hogy lehetne ezt jól megoldani. A pontszáma mindenesetre prominensen lesz szerepeltetve, illetve rendezheted is aszerint.
46

Hát szerintem válassz két

inf · 2015. Okt. 23. (P), 12.29
Hát szerintem válassz két szép háttérszínt a hozzászólásnak, aztán belövöd, hogy 0 like az egyik háttérszín, 10+ like a másik háttérszín. Közte meg csinálsz egy átmenetet 0-10-ig. Persze ez csak egy vélemény, nem értek a design-hoz.
55

Nos, a technológiához nem

tóthika · 2015. Okt. 25. (V), 01.20
Nos, a technológiához nem értek, de bizonyára hasznos felületként használható.
Azt viszont nem értem, miért kellene moderálni (ennél jobban) a hozzászólásokat. Nincsenek olyan kirívó személyek itt, a fórumon, akik folyamatosan zavarnák a honlap életét. Mindenki megoszthatja tudnivalóit, és ha valaki butaságot beszél, felvilágosítják, hogy az nem úgy van. Ha eltüntetnénk a rossz hozzászólásokat, és valaki ugyanúgy gondolja, mint akit eltüntettünk, felteszi ugyanazt a kérdést, és ő sem kapja meg rá a választ. Az meg, hogy a hozzászólásokat értékelve le lehet húzni a többi hozzászólást, abszurd.
Fejleszthetitek a moderációt, csak az a baj, hogy lassan el fog fogyni a tartalom. Poetrón kívül itt senki más nem tesz azért, hogy legyen egy nagyobb vérfrissítés. Nem a régi külsővel, hanem a használhatósággal, a beviteli felületekkel van gond - nomeg az is gond, hogy automatikusan nem lehet cikkeket megjelentetni. Nincsenek új technológiákról szóló témák, se új arcok. Már nem pörög az oldal.

Ettől függetlenül remélem, még sok minden megél majd az oldal. Én most itthagyom az oldalt, remélem, egy év múlva, mikor visszajövök, rá se fogok ismerni :)