Příspěvky

976

Vývoj / Re:licence aplikace v certifikačním klíči

« kdy: 16. 02. 2018, 19:54:20 »

Bez nějaké online funkcionality je to ale celé skoro na nic, skutečně stačí ten klíč zkopírovat a vy se o tom stejně nedozvíte. Trochu lepší bude, pokud klíč odvodíte z hardwarových parametrů počítače u zákazníka (max adresa, cpuid + pár dalších parametrů) a budete kontrolovat, že program běží stále na tom stejném hardware, ke kterému byl vydán. Budete tedy vydávat klíč teprve na základě údajů, které vám zákazník pošle. Pokud dojde ke změně hardware, bude muset zákazník dostat nový klíč. Aby klíč zkopíroval, musí nasimulovat stejný hardware, což je o dost těžší, anebo musí pozměnit v programu tu funkčnost, což je také těžšší než pouhé kopírování.

A naopak - pokud tam bude online funkcionalita, pak jen stačí, aby aplikace posílala ten klíč k ověření a vy abyste ho online ověřil, takže pak nemusí být v aplikaci ani samotný ověřovací algoritmus. Funkčnost bude podobná, jako při přihlášení heslem, akorát uživatel heslo (klíč) nebude ručně zadávat. Na serveru klíč ověříte vůči svojí databázi, kde zkontrolujete, zda byl tento klíč danému zákazníkovi vydán - budete ho muset nějak identifikovat (opět nějaký otisk, veřejná IP adresa apod.). Tady by musel zákazník podvrhnout váš ověřovací server, což je taky o trochu těžší. Neobvykle velké využití určitého klíče můžete na serveru taky detekovat, což je výhoda.

Otázka nicméně je, jestli se to celé vyplatí. Jednoduché varianty lze příliš snadno přelstít a zaručená ochrana asi vůbec neexistuje (přesvědčí mě někdo o alespoň teoretickém opaku?). Jsou knihovny, které většinu práce udělají za vás, ale stejně ... v čem vám to pomůže? Nejspíš chcete vědět, kolik instancí vaší aplikace se reálně používá a asi taky chcete zákazníky nějak smluvně vázat - a k tomu stačí licenční smlouva a nějaký jednoduchý sběr statistik o využívání programu (program bude posílat nějaké metriky někam na server). Tím možná zjistíte víc zajímavých informací a budete mít i právně větší jistotu pro případ sporu (pokud vám licenční smlouvu napíše specialista).

Takže nevím, zda má cenu se snažit udělat něco, co dobře ani udělat nejde (zaručená kontrola), nebo zda raději udělat dobře něco, co dobře udělat jde (smlouva+metriky).

977

Vývoj / Re:Abuzus XML v Javě

« kdy: 14. 02. 2018, 11:34:11 »

Ehm, mluvime tady jaksi v urcitem kontextu.
A v kontextu webu, kde dneska vladne Javascript (a AJAX Primefaces je jenom priklad, klidne mozno dosadit REACT) znamena, ze XSLT transformace pro WEB je k nicemu.

To je otázka, zda zde jde o kontext webu. Dost pravděpodobně ne - alespoň ne u původního dotazu. Takže ten  spor dost postrádá smysl. Prostě je tu víc nástrojů a každý se hodí pro něco jiného. Apriori zatracovat xslt bez znalosti kontextu mi přijde jako holý nesmysl.

978

Vývoj / Re:Abuzus XML v Javě

« kdy: 13. 02. 2018, 21:04:43 »

1. K čemu je samotná validace xml bez následného načtení xml např kvůli vložení do db? V tom připadě, standardní způsob je si prostě udělat modelové třídy xml souboru, obohatit to třeba o Hibernate Validator (přes anotace vč. custom validací). Tzn. tady v tomto use case já můžu jednoznačně validovat až na straně javy a nepotřebuju takový zbytečný alá-xsd formát, protože stejně potřebuju mít modelové třídy.

Samotná validace je očividně k tomu, aby bylo to xml podle určitých kritérií validní. Bez návaznosti na zbytek to nelze nijak odsoudit.

2. Řekněme, že z nějakého úchylného důvodu ja budu chtít XML opravdu jen validovat a dál s jeho obsahem nijak nepracovat. V tom případě opět nechápu, proč se trápit s takovýmto alá-xsd frameworkem - vždyť místo alá-xsd si k tomu xmlku napíšu obyčejné POJO třídy, opět si tam dám standardní Hibernate Validator anotace, a jako input do té utilitky si dám prostě to xmlko a to POJO. Bude to 100x lepší, než se štvát s nějakým takovým zbytečným frameworkem, protože budu mít statickou typovou kontrolu a podle mě to bude v Javě i pěknější.

Co mi příjde zvláštní, ta firma to má očividně jako svůj produkt a asi se to snaží prodávat. Musím říct že teď, po tom, co jsem viděl, se mi k nim moc nechce. Navíc to, co oni vytvořili, přesně umí Saxon Processor, který je placený, pomocí XSD 1.1 assertion dokáže zavolat javovskou metodu z classpath.

Volat javovskou třídu z xslt umí kde kdo - saxon, xalan... Ideální je postavit tu validaci na těchto nástrojích. Opět, nic špatného na tom v principu nevidím - pokud jde o primární formát pro výměnu nebo ukládání dat, je jedině dobře, že to validují. Zvrhlé by naopak bylo to xml mít nevalidované - což je bohužel taky dost častý případ.

Jinak pochybuju, že by tím produktem byl jen nástroj na validaci, nejspíš kolem toho bude nějaký ekosystém, který může dávat jako celek smysl. Řada organizací potřebuje držet kontinuitu po mnoho let, takže nějaký formát s dobrou specifikací a ověřenou implementací - či rovnou s více nezávislými implementacemi - je ideální.

979

Vývoj / Re:Co programovat? Velké dilema

« kdy: 09. 02. 2018, 00:29:39 »

To je jako kdyby se malíř vyptával kolemjdoucích na ulici, co má namalovat, protože jeho nic nenapadá. V takovém případě by snad bylo lepší nemalovat raději vůbec nic.

V užitém umění je běžné, že chce umělec dělat něco, co bude sloužit někomu jinému. Programování by se mohlo  tomu užitému umění v ledačem podobat .

Pak je také jiný druh umění, kdy umělec (může, ale nemusí být geniální) tvoří z jiných důvodů a pak tvoří klidně do šuplíku, zájem okolí ho moc nezajímá (případně ho dokonce obtěžuje). To je zase jiná situace. Čistý výzkum nebo věda by se mohly zase podobat této variantě.

980

Hardware / Re:Stačí dvoujádro na vývoj v Javě?

« kdy: 06. 02. 2018, 14:48:33 »

Pod 16G RAM bych nešel a určitě se vyplatí SSD.

981

Studium a uplatnění / Re:Loajalita - nedává mi smysl

« kdy: 03. 02. 2018, 18:57:06 »

Loajalita má smysl pokud je oboustranná a jako taková je součástí firemní kultury. IMHO se něco takového daří spíš výjimečně a to ještě jen u malých firem, kde je vše na osobní úrovni a zaměstnanci mají přímý zájem na rozvoji firmy. Často pomůže, pokud nejsou peníze jediné kritérium. Pokud založím ve třech lidech firmu, budu jaksi loajální z principu. Částečně se to pak dá rozšířit na větší firmy.

982

Vývoj / Re:Seriozní porovnání .NETu a Javy

« kdy: 02. 02. 2018, 16:20:19 »

Když někdo tvrdí, že Java je multiplatformní, tak má asi dost nízké požadavky na multiplatformní aplikaci.
Ono je i otázka, co to tedy přesně je. Například bych čekal, že pokud mám JavaAplet z roku 2001, který mi běžel i v prohlížeči, tak dneska ho spustím i na Androidu. To je přece taky Java, není? Třeba. A přitom už tenkrát to nebeželo v Nokii, kde taky byla Java... Taky nevím, co budou dělat se Swingem v tabletu... zvlášť když v něm bude třeba iOS.

Takových prostředí, které fungují stejně od roku 2001 a jsou podporované na platformách, které tehdy ani neexistovaly,  moc nenajdete (čest vyjímkám). Na druhou stranu, se spuštěním java aplikace z roku 2001 budete mít na současném počítači pravděpodobně méně problémů než při spuštění aplikace v jiném jazyce. Běhové prostředí je samo o sobě i docela dobře definováno (takže těžko vyčítat javě že na mobilu nespustíte aplikaci pro desktop).

Zkuste si spustit normální C nebo C++ program z roku 2001 a budete docela zápolit - se starou distribucí na současném hardwaru nebo se starším toolchainem na současné distribuci. Nejsnáze byste to asi vyřešil virtualizací, což by ale nevypovídalo nic o přenositelnosti a neměnnosti vývojové platformy jako takové.

983

Vývoj / Re:Seriozní porovnání .NETu a Javy

« kdy: 02. 02. 2018, 16:02:52 »

Dneska i armáda nebo industry používá tablety, tak co tam s tím Swingem budete dělat? To už mi příjde lepší použít ten Xamarin když už, a to je .NET. Mám prostě víc a víc dojem, že Java celkově je dožívající technologie.

Nemyslím, že by byla java dožívající. Žije to mimo jiné o díky novým  jazykům nad jvm a ekosystému okolo, takže se celé to prostředí naopak spíš posouvá a vyvíjí dál, nikoli na úkor javy ale v symbióze s ní.

Místo swingu je tu javafx, která vypadá dost současně a dobře se používá. Divím se, že není víc vidět.

984

Vývoj / Re:Bezestavové OOP

« kdy: 01. 02. 2018, 18:07:44 »

Rozdíl mezi konstruktorem a setterem je jen a pouze v tom, že konstruktorem hodnoty nastavuješ povinně, zatímco setterem volitelně.

Netýká se to moc tématu, ale tak pro zajímavost - velký rozdíl mezi konstruktorem a setterem je ten, že pomocí konstruktrou nelze vytvářet cyklické struktury (objekt A referencuje B, B referencuje A).

No to platí v javě, protože konstruktor lze použít jen jednou a java používá Call_by_value takže zvnějšku už to nezměním.

Ale platí to i v C#? Když tam zdá se můžeme použít i Předávání parametrů odkazem (ref) takže bych mohl nastavit prázdný ukazatel jako výstupní parametr a ten pak dodatečně změnit?

?? (C# neznám...)

985

Vývoj / Re:Jak vytvořit v php objekt kontroleru jehož název je v poli

« kdy: 01. 02. 2018, 12:47:15 »

Stačí mít plně kvalifikovaný název ve stringu:

$className = '\Foo\Bar\MyClass';
$instance = new $className();

Tohle je správná odpověď. Naplňte si

Kód: [Vybrat]

$className

a pak můžete udělat tu instanci. Pokud zavoláte konstruktor přímo, musíte už předem vědět, kterou třídu budete instancovat, což právě nevíte. Pokud chcete instancovat třídu v závislosti na datech například z url, musíte použít proměnnou.

Budete u toho muset taky ošetřit, když v ní bude jméno neexistující třídy anebo když by tam bylo jméno jiné třídy než controlleru. Mimo jiné to má význam pro bezpečnost.

986

Studium a uplatnění / Re:Mám všechno zapomenout a učit se Javascript?

« kdy: 01. 02. 2018, 12:27:23 »

V JS i nezkušený člověk dokáže udělat robustní a rychlý kód,

Nevím nevím jestli to není moc silné tvrzení. Ani s tou rychlostí vývoje to nevidím tam růžově.

Udělat to stejné v c++ je mnohem dražší, zase performance c++ je stabilní, u js to skáče sem a tam (gc, single thread).

Tohle asi souhlasí.

987

Vývoj / Re:Bezestavové OOP

« kdy: 30. 01. 2018, 20:10:14 »

@BoneFlute

Ne, že by se to neosvědčilo, ale nebyla možnost něco paralelizovat a tudíž stavovost objektů nebyla na závadu.

Pokud není stav sdílený mezi vlákny tak stavovost objektů nikdy nevadila.

988

Vývoj / Re:Bezestavové OOP

« kdy: 30. 01. 2018, 16:30:19 »

XML splitter bych taky udělal stavově, časem nejspíš přibudou další metody které budou operovat nad stejným xml.

989

Vývoj / Re:Seriozní porovnání .NETu a Javy

« kdy: 30. 01. 2018, 14:50:13 »

Pokud to chcete čisté, použijte Optional. IMHO se moc netýká srovnání java vs. .NET.

Jinak už ta formulace dotazu je zavádějící - srovnávejte srovnatelné (jazyk s jazykem, runtime s runtimem,  framework s frameworkem). Takže  by  měla být srovnávána např. java vs. C#.

990

Vývoj / Re:Využití cachování na disk u virtuálního stroje (Java, .NET)

« kdy: 29. 01. 2018, 00:55:22 »

Není mi jasné, proč nemůžete to několika gigové xml načíst do paměti celé bez swapu? Je na tom stroji málo paměti? Pak by to mohl možná  zachránit swap na extra rychlý SSD disk, ale hádám, že to bude i tak řádově pomalejší.

Pokud je málo RAM, tak mě ještě napadá nějaká on the fly komprese - zram nebo něco xml-specifického.

Jinými slovy - nejste jediný, kdo pracuje s velkým xml a chce mít jednoduchý kód, jak to dělají ostatní?