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 - Ondrej Nemecek

Stran: 1 ... 71 72 [73] 74 75 ... 90
1081
Vývoj / Re:Nasazeni Google recaptcha - nazory
« kdy: 20. 07. 2017, 17:47:31 »
Google recaptchu bych určitě nenasazoval. Není problém si udělat jednoduchou captchu ve stylu jako je tady na rootu anebo použít hotové řešení, které ale poběží na vašem serveru.

1082
Server / Re:Eshop engine - doporučte
« kdy: 19. 07. 2017, 10:47:27 »
Máte někdo zkušenost s https://www.broadleafcommerce.com/ ?

Mam zkusenosti z produkcniho nasazeni. Pokud se nic nerozbije pak je to fajn.

Zkušenost jako provozovatel e-shopu nebo jako vývojář? S komunitní verzí nebo placenou?

1083
Server / Re:Eshop engine - doporučte
« kdy: 19. 07. 2017, 10:46:17 »
Používal jsem Zen Cart[1] a měl jsem v plánu nasadit Phoca Cart[2]

Zen Cart fungoval a byl poměrně jednoduchý (až na správu obrázků), ale několikkrát mi ho hackli. Phoca Cart jsem už nestihl nasadit do ostrého provozu, eshop jsem ukončil z důvodu nevýdělečnosti.

[1] https://www.zen-cart.com/
[2] https://www.phoca.cz/phocacart

Zen Cart doporučuju nebrat, je to zastaralý neudržovaný software. Lepší je OXID eShop, který je v komunitní verzi zdarma. Sice taky není moc moderní, ale je dobře udržovaný a technicky ještě snesitelný. Nejmodernější je Prestashop, nicméně poslední verze se moc nevyvedla a obecně má v některých případech problém s výkonem a chybama.

1084
Server / Re:Eshop engine - doporučte
« kdy: 18. 07. 2017, 22:17:58 »
Máte někdo zkušenost s https://www.broadleafcommerce.com/ ?

1085
Vývoj / Re:Implementace rozhraní v Javě
« kdy: 13. 07. 2017, 14:02:13 »
(...) Rozhodne bych to nedelal. Pouzit jednu implementacni tridu na vice rozhani doporucuji jen v extremnich pripadech (...)

Ještě máme defaultní implementace metod v rozhraní, což někdo používá jako traity. To tam těch rozhraní pak může být docela dost a IMHO to není nic proti ničemu.

Obecně mi nepřijde nic špatného na tom, když nějaká třída implementuje více rozhraní. Jestli je návrh dobrý nebo se pozná podle spíš podle toho, která konkrétní rozhraní to jsou - jestli jde o smysluplnou kombinaci funkčnosti.

V případě, že dvě rozhraní mají metodu se stejnou signaturou ale jinou sémantikou, tak to smysluplné podle mě není, protože bych měl mít vždy možnost napsat pro ně i dvě odlišné implementace, což ale nemám, čím vzniká bezprostředně problém. A naopak v případě, že by ta sémantika byla stejná, tak mi to přijde sice lehce varovné, ale ještě přijatelné. Varovnost spočívá v tom, že pokud by ta rozhraní byla určena pro společné použítí a měla mít společnou metodu, byla ta metoda nejspíš ve společném předkovi těch dvou rozhraní. Pokud to tak není, může to znamenat, že v té implementaci chci kombinovat příliš funkčnosti naráz a mohla by být lepší ta kompozice, jak již bylo řečeno.

1086
V Biosu :-)

1087
Hardware / Re:Wi-Fi Atheros - pomalý web
« kdy: 10. 07. 2017, 14:23:14 »
Moc velkou šanci „opravě“ toto laptopu nedávám, je to low-end a určitě se šetřilo kde to šlo. Podle mě nemá cenu se s tím nervovat, šance nebude velká.

Osobně bych zkusil ještě nabootovat linux z nějakého live CD, abych ověřit, že to není nějaká specialita windows nebo ovladače pro windows (nebylo by to poprvé). Pak bych ještě zkusil vyměnit wifi zařízení na straně AP (třeba si někde něco půjčil) anebo na straně toho laptopu (což chcete stejně udělat). A nakonec bych koupil usb wifi, protože mít v šuplíku usb wifi s možností připojit anténu se tak jako tak hodí, stojí pár kaček.

Pak bych vzal tu vrtačku a vrtal díru do zdi :-)

1088
Hardware / Re:Wi-Fi Atheros - pomalý web
« kdy: 09. 07. 2017, 17:05:24 »
Nepotřebujete až tak vysokou rychlost, potřebujete hlavně stabilní linku. IMHO „pomalý web“ znamená právě nestabilní linku - kolísá rychlost, kolísá latence, kolísá chybovost a to vše typicky až při zatížení linky. Takže se nedonačtou všechny zdroje k dané stránce a ta se načítá třeba minuty.

Takže bych měřil při zatížení sítě na 50-80% z nastavené maximální přenesové rychlosti. Začal bych na nejnižších hodnotách přenosové rychlosti a postupně zvyšoval a porovnával hodnoty.

Zatížení je důležité kvůli tomu, aby bylo měření o něčem vypovídající (odpovídalo praktickému provozu). Na nevytížené lince to bude totiž klidně chodit zdánlivě v pořádku. A naopak pokud byste linku vytížil nadoraz, dostanete špatné parametry vždy (i na stabilní lince).

Podíval bych se na RTS Treshold a Fragment Threshold. Nějaké info třeba tady
http://forum.zive.cz/viewtopic.php?t=128675 a http://wiki.pvfree.net/index.php/Nastaveni_RTS/CTS

Wifi standardy běžící na pásmu 2.4 GHz mají lepší průchod přes překážky, ale pásmo je ale více zarušené. U vás musíte na 2.4GHz běžet, máte AP i klienta 2.4GHz, zajímavé by ale bylo přesto změřit na 5GHz.

Doporučuju ještě zkusit USB wifi typu https://www.alza.cz/tp-link-tl-wn722n-lite-d155291.htm Má ta často lepší signál než vestavěné wifi a navíc k tomu jde připojit externí anténa, čož se může hodit.

A připojení „do vedlajsej izby“ bych stejně řešil dírou do zdi a ethernetovým kabelem, to je jistota a kvalitou ani cenou se tomu nic nevyrovná :-)

1089
Software / Re:Evidence odpracovaných hodin
« kdy: 07. 07. 2017, 15:24:40 »
Produktivita je speciální případ efektivity:

Kód: [Vybrat]
Efektivita = Výsledek / Náklady

Pokud jste schopni kvantifikovat výsledek a náklady, máte efektivitu (v použité metrice).

V manuální rutinní činnosti je metrika jednoduchá - stačí mít výsledek kvantifikovaný třeba počtem kusů a náklady potřebným časem a počtem zaměstatnců. Složitější to ale začne být, pokud do kvantifikace výsledku započítáte třeba životnost těch vyrobených kusů a do nákladů třeba opotřebení výrobní linky nebo fluktuaci zaměstnanců. Pak už je to docela komplexní problém.

U tvůrčích činností pak komplexita vyhodnocení efektivity asymptoticky roste do nekonečna, což jasně signalizuje, že takto pojatá efektivita zde zcela ztrácí opodstatnění a nemá moc smysl. Jak chcete kvantifikovat výkon vědce (a že se o to zuřivě snaží citační indexy apod.)? Nebo spisovatele, malíře (kde se skutečná kvalita díla ověří až po staletích a nelze ji ani vyjádřit číselně)?

Co se týče programování - může spadat do obou kategorií, podle toho, jakého je druhu.

Pokud je cílem firmy vydělávat peníze, bude její vedení nakonec stejně zajímat jen jedna efektivita: Kolik se v daném čase vydělalo peněz. Ty údaje zná vedení firmy a pokud chce, aby zaměstnanci znali svoji výkonnost, bude s nimi tyto údajů sdílet, případně je rovnou přizve do spolurozhodování. Pokud je to možné, pak lze uvažovat o něčem jako je svobodná firma, viz. např. https://www.tomashajzler.com/tema/svobodna-firma

1090
Já bych to řešil úpravou úrovní nebo křivek, výsledek by mohl odpovídat záměru - tj. prosvětlení stínů aniž by fotka příliš utrpěla ve slunných místech. Křivku si můžete vymodelovat i ručně (umí to snad všechny programy, v Gimpu je to třeba Barva - Úrovně nebo Barva - Křivky).

Jde to docela rychle a pokud je více fotek se stejnou světelnou dynamikou lze stejnou křivku použít automatizovaně i na více fotek (alespoň v některých programech).

Na automatickou úpravu úrovní u fotek s různou dynamikou budou existovat pluginy (interně budou na úpravě úrovní založené), ale nemusí se vždy trefit do Vašeho očekávání. Záleží na kvalitě těch pluginů.

1091
Pokud někomu přijde Git a Mercurial složitý, můžete začít s fossilem http://fossil-scm.org/  :) Pak lze mít repositář na serveru (spustí se triviálně) nebo na usb flash, pokaždé to je jen jeden sqlite soubor, základní ovládání je podobné jako u gitu a možnosti jsou podobné. Není tak rozšířený, ale pro řadu použití mi přijde dost praktický. Přechod na git je pak otázkou naučit se dalších 5 příkazů. Pro složitejší případy použití se pak sice už liší víc, ale tak daleko tazatel není. Jedinou relativní nevýhodou je nulová podpora v IDE a použití z příkazové řádky.

https://www.slant.co/topics/370/versus/~git_vs_mercurial_vs_fossil

1092
Vývoj / Re:OOP a servisní třídy
« kdy: 27. 06. 2017, 13:41:52 »
To co já nazývám servisními objekty, nebo často servisními interfacemi jsou objekty/interface, které obsahují hromadu metod, které spolu moc nemusí souviset, některé jsou stavové, jiné bezstavová, často jsou tam továrny. Zahrnutí do interface má ten význam, že skrývám implementaci, buď proto, že nechci aby byla vidět, nebo většinou proto, že v tom místě není definována (je dodána později). To třeba umožňuje nahradit skutečnou implementaci mockupem.

Takže servisní interface = fasáda?

1093
Desktop / Re:Remote desktop Ubuntu - Windows
« kdy: 27. 06. 2017, 12:31:18 »
Na pomalejší lince mi nejlépe fungoval X2GO.

1094
Hardware / Re:Lacný komp za 115 Eur
« kdy: 26. 06. 2017, 21:36:51 »
Také doporučuju importpc.cz Takovým firmám udělám rád reklamu, protože jsou velmi ochotní, reagují okamžitě a všechny technikálie přesně odpovídají skutečnosti. Na České poměry je to malý zázrak :-D

1095
Vývoj / Re:OOP a servisní třídy
« kdy: 24. 06. 2017, 21:55:36 »
Podle mě jeden o voze a druhý o koze. Skutečně je to hlavně o tom, co se tou servisní třídou vůbec myslí.

Stran: 1 ... 71 72 [73] 74 75 ... 90