Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - gill

Stran: 1 ... 16 17 [18]
256
Server / Re:MySQL a phpMyAdmin jako informační systém
« kdy: 17. 04. 2019, 11:42:36 »
Mně na tom nejvíc zaráží, že hledám nástroj natolik univerzální a primitivní a nenacházím. Jako by si každý budoval svůj vlastní frontend s kompletní logikou, byť chce třeba jen evidovat seznam knih ve dvou uživatelích.

neznam reseni, ktere by kombinovalo ciste sql webove interface a formulare s validacemi na strane aplikace. Pro formulare a seznamy s jednoduchym filtrovanim je celkem pouzitelny django admin.

257
@TomBA_SK, @Marek Staněk
chromebook nema klavesy: Home/End/Ins/Del, PgUp/PgDown, Super(Win), Menu, Fn, CapsLock
a nema Fkeys i kdyz se namapujou(povolej?) tak F11 a F12 budou nekde mimo horni radu
(ze to nema numlock neresim, ale ani bych nechtel pripojovat USB keypad :-)

efektivnejsi je si zvyknout na emacs style zkratky. V gtk aplikacich jdou zapnout globalne. I na chromebooku.

gtk-key-theme-name = Emacs

v ~/.config/gtk-3.0/settings.ini

a premapovat search klavesu na ctrl

258
O serveru Root.cz / Re:Osvědčila se povinná registrace?
« kdy: 14. 04. 2019, 13:36:39 »
Problém je s tím určení off-topic příspěvku.

O topic podle vseho nejde. Muj neschvaleny prispevek se jen dotazoval na zdroj tvrzeni v jinem prispevku. Tedy topic stejny.

259
O serveru Root.cz / Re:Osvědčila se povinná registrace?
« kdy: 14. 04. 2019, 12:43:39 »
Co ale považuji za nešikovné, je schvalování komentářů. Zajímaly by mě důvody, které vedly k zavedení a zároveň až do současné chvíle neodstranění schvalovacího procesu. Osobně mám pár tipů, proč tomu tak může být. Neplánuje se do budoucna nějaký whitelist?

souhlasim s neschvalovanim off-topic prispevku. Co se mi nelibi je selektivni politicka cenzura pod clanky jako je ten o Assangovi. V takovem pripade by bylo lepsi zakazat celou diskuzi. Lzive ocernujici prispevky jsou povoleny, reakce na ne uz ne. Podobnych ocernujicich prispevku na Assange je v poslednich dnech plny internet. Spolupracuje redakce s nejakou PR agenturou?

260
Vývoj / Re:Je Swagger utter crap?
« kdy: 05. 04. 2019, 10:45:30 »
Standa Blabol:

Co je spatneho na WSDL co ma include XSD a dalsi a dalsi? To WSDL se prece da vygenerovat na zaklade XSD schematu. Ty ho pak pouzijes pro SOAP UI nebo pro vygenerovani Clienta.

kdyz ti nevadi, ze zbytecne posilas tuny sracek. Treba u mobilnich aplikace to muze vadit.

To te prce nemusi moc zajimat, co v tom WSDL presne je, nemusis si ho cist. Ne snad?

jen dokud vse funguje.

261
Vývoj / Re:Je Swagger utter crap?
« kdy: 04. 04. 2019, 11:23:44 »
U jednodussich aplikaci je navrh API odshora overkill. Lepsi vychazet z ORM modelu.

262
O serveru Root.cz / Re:Osvědčila se povinná registrace?
« kdy: 01. 04. 2019, 15:58:48 »
Ja jsem spokojeny. Predtim tu vetsinu dotazu generoval jeden uzivatel (javaman) pod ruznymi prezdivkami. Clovek casto plytval usilim na odpovedi jen aby zistil, ze tazatel je troll.

263
Vývoj / Re:práce s JSON objekty v AJAX Success
« kdy: 28. 03. 2019, 15:48:27 »
Druhá věc je – opravdu to píšete v čistém JavaScriptu, nepoužíváte tam žádnou knihovnu, třeba jen pro ta AJAXová volání? Snad každá knihovna ten jeden řádek pro parsování JSONu zavolá za vás.

lepsi pouzivat Fetch API. Uz je podporovane ve vsech prohlizecich.

264
Vývoj / Re:JS - naplnění assoc array pomocí proměných
« kdy: 17. 03. 2019, 08:32:23 »
Citace
var Array = [];
tohle uz priste nedelej, tohle je fakt spatny pojmenovani.

Hlavne by to mel byt objekt {}. Pojmenovani by nevadilo, kdyby se to pouzivalo jako pole.

265
Vývoj / Re:JS - naplnění assoc array pomocí proměných
« kdy: 16. 03. 2019, 18:16:09 »
Asi bych volil prvni verzi bez tech nadbytecnych promenych.

Jinak bych doporucil uzavrit to do formulare a misto id pouzivat name.

266
Já reagoval na to, podle čeho soudí Kit, že nepoužívá parse. Což neimplikuje, že to vidím stejně.

ja reagoval na jeho prvni prispevek

Nevrací to jako asociativní pole, ale jako JSON. Zpracovává se to metodou JSON.parse().

267
podle ceho soudis, ze nepouziva parse?

Každopádně i bez 'parse' to rozklíčuje a hodnoty vsadí přesně jak potřebuju.

ten callback success to dostane rozparsovane. Nekde se to parsovat musi.

268
Nevrací to jako asociativní pole, ale jako JSON. Zpracovává se to metodou JSON.parse().
díky za info..

Já to ještě na úrovni PHP encoduju do jsonu a ten pak echuju ven a Ajaxem zpracovávám.
Každopádně i bez 'parse' to rozklíčuje a hodnoty vsadí přesně jak potřebuju.

To je právě špatně, takový skript je zranitelný. Proto parse().

podle ceho soudis, ze nepouziva parse?

269
Software / Re:Nahradenie hex stringu
« kdy: 10. 03. 2019, 16:54:21 »
Jo, a jak poznám, kdy mi to odswapuje a kolik to skutečně sežere paměti? Co jsi mi chtěl vlastně sdělit konkrétního?

to nepotrebujete vedet. Ani pri tom "sekvencnim" cteni neznate velikost bufferu.

270
Software / Re:Nahradenie hex stringu
« kdy: 10. 03. 2019, 09:34:23 »
Bez zaruky a bez krasy:

#!/usr/bin/env python3

import sys

def findIndex(f, sa):
    ri = 0
    ra = []
    sl = len(sa)
    while True:
        try:
            b = f.read(1)
            if (len(b) == 0):
                raise EOFError()
            ra.append(b[0])
        except EOFError:
            return -1
        ri += 1
        if (len(ra) > len(sa)):
            ra.pop(0)
        if (ra == sa):
            return ri - sl


def write(f, index, s):
    f.seek(index)
    f.write(s)


def replace(fn, ih, oh):
    f = open(fn, "rb+")
    index = findIndex(f, list(bytes.fromhex(ih)))
    if (index == -1):
        print("Not found")
    else:
        write(f, index, bytes.fromhex(oh))
    f.close()


if __name__ == '__main__':
    if (len(sys.argv) != 4):
        print("Usage: %s filename inhex outhex", sys.argv[0])
    else:
        replace(sys.argv[1], sys.argv[2], sys.argv[3])


to je hodne neefektivni. Pouzijte radeji mmap.

Stran: 1 ... 16 17 [18]