Příspěvky

3556

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

« kdy: 03. 02. 2018, 18:37:08 »

Co to je za logiku toto, nelíbí se mi Tomcat, tak můžu použít jetty nebo Undertow. Proč by se ti neměl líbit Tomcat? Tahle mentalita mě fakt strašně štve, protože kvůli toho jsou v Javě dva zadky frameworků typu "blbý a blbější".

Tomcat se vám třeba nemusí líbit proto, že neposkytuje nějakou funkci, kterou jiný server poskytuje. To, že máte na výběr z různých variant, je výhoda, můžete si vybrat to, co vám vyhovuje nejlépe.

3557

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

« kdy: 02. 02. 2018, 13:18:06 »

riesit multiplatformovost, ked aplikacia je urcena pre windows uzivatelov?

Otázka je, jak jste přišel na to, že je aplikace určená pro uživatele Windows.

Pockat, co to melete? Ja vravim, ze to posudi firma.

Hlavně že jste to citoval, že? Já v tom tučném tedy „posoudí to firma“ nevidím.

3558

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

« kdy: 02. 02. 2018, 13:17:03 »

.Net core je primarne urcene pre servrove aplikacie, na dektop sa netlaci.

Ano, to jsem se vám snažil naznačit, že v souvislosti s desktopovými aplikacemi nemá smysl psát o .NET Core.

3559

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

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

riesit multiplatformovost, ked aplikacia je urcena pre windows uzivatelov?

Otázka je, jak jste přišel na to, že je aplikace určená pro uživatele Windows.

Ja si tiez myslim, ze na strane klienta je multiplatfromovost precenovana.
Hlavne sa mi paci to neustale vyzdvihovanie multiplatformovosti, no ked ju uz .Net Core dosiahol, zas fnukaju nad dacim inym.

Já si zase myslím, že je přeceňované .NET Core, pokud jde o aplikace na straně klienta, zejména o aplikace pro desktop.

3560

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

« kdy: 01. 02. 2018, 22:01:25 »

Presne tak. Treba tiež vziať do úvahy, kto sú tí 10%. Trebárs vezmime si štatistiky podielu server-side
jazykov. PHP 83.1%, ASP.NET 14.1%, Java 2.4%, static files 1.5%, ColdFusion 0.6%, Ruby 0.5%,
JavaScript   0.4%, Perl   0.3%, Python 0.2%, Erlang   0.1%.
https://w3techs.com/technologies/overview/programming_language/all

Java má minimálny podiel na celkovom trhu, točia sa však tam najväčšie peniaze. Odráža sa to aj
tým, že Java vývojári majú vo všeobecnosti vyššie mzdy ako majú PHP programátori.
Multiplatformovosť je dôležitá; z Windows MFC prešli v segmente grafických a animačných softwérov
mnohí na Qt knižnicu. Pretože v ich branži sa často pracuje s Mac a Unix systémami.

To jste ovšem zatajil takovou drobnost, že jde o statistiku programovacích jazyků webových stránek. Na aplikačních serverech bude nejspíš Java převládat. To dělá tu většinu podílu na celkovém trhu, ne nějaké webové stránky.

3561

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

« kdy: 01. 02. 2018, 20:24:15 »

Tu si treba uvedomit jednu vec. Bavime sa o desktope, ano? A pokial mi dobre sluzia vsetky zmysly, tak na desktopoch je najviac rozsireny windows, takze nejaku multiplatformovost netreba riesit, ak budu vsetci uzivatelia windows-oriented. Pretlacat niekde mjltiplatformovost a argumentovat tym, to je asi dnes taky modny hit

„Nejvíc rozšířený“ je pěkný nesmysl. „Nejvíc rozšířený“ prohlížeč je Chrome, který má 60 % uživatelů. Opravdu hodíte 40 % uživatelů přes palubu? Windows mají na desktopu podíl okolo 85 %, Mac má kolem 10 %. Ani to není rozložení, nad kterým by bylo možné mávnout rukou a dělat vše Windows only. Zvlášť když klesá podíl desktopu jako takového.

3562

Vývoj / Re:Přihlášení pomocí tokenu a zvýšení bezpečnosti

« kdy: 01. 02. 2018, 17:43:13 »

Nejde o to, že je to málo pravděpodobné, ale o to, že asi většina případů, kdy něco takového může nastat, spočívá v tom, že útočník ovládá uživatelův prohlížeč. V takovém případě může útočník poslat jakýkoli požadavek z jeho IP adresy a se všemi údaji, které zadává uživatel. Takže bránit se takovému útoku je marné. Takže zbývají případy, kdy by se útočník dostal k local storage kvůli nějaké chybě prohlížeče. Jenže prohlížeč může mít chybu i v úložišti cookies, uložených hesel, obraně proti cross-site scripting – stejně tedy nenajdete technologii, která by byla v prohlížeči zaručeně bezchybná.

3563

Vývoj / Re:Přihlášení pomocí tokenu a zvýšení bezpečnosti

« kdy: 01. 02. 2018, 16:03:08 »

Kontrolovat IP adresu klienta byl hodně hloupý nápad už před lety, a od té doby se pravděpodobnost, že se IP adresa klienta bude měnit, ještě podstatně zvýšila.

Pokud se někomu podaří dostat ke klientskému local storage, má dotyčný uživatel pravděpodobně mnohem větší problém, než že se někdo může přihlásit k vaší aplikaci.

3564

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

« kdy: 01. 02. 2018, 14:49:17 »

to na co ste pred par rokmi potrebovali reSharper, dnes zvlada Visual Studio vo free verzii nativne. Niektore veci mi tam chybali, no na to sa daju najst pluginy. Povezdme, ze Roslin ako "compiler as a service" bol genialny napad.

Vím, že se VS za poslední dobu docela zlepšilo. Šlo mi o to, že to není tak, jak to bylo původně formulováno – že VS je skvělé IDE, které teď Idea dohání. Je to přesně naopak, Idea je špička už spoustu let, a VS se tomu v poslední době přibližuje.

Podobneh chovanie viem v C# dosiahnut pomocou implementacie kovariantneho generickeho interface.

S tím ale musí počítat i ten předek, ne?
S tym vysie uvedenym som sa v praxy este nestretol, ake to ma vyuzitie a prakticke dopady?

AKo mne osobne by v Jave chabli skutocne  genericke typy (ak pisete infrastrukturny kod zo skutocnou generikou je svet ovela lahsi)

Souhlasím a vadí mi, že to (pokud vím) není mezi změnami, o kterých by se reálně uvažovalo.

tiez som v nej mal neskutocny posit neslobody a kod v nej bol vzdy dlhsi a ukecanjsi.

Podle mne svoboda do zdrojových kódů nepatří. To není umělecké dílo, kde se bude někdo kochat, co originálního tam kdo vymyslel. Mně vadí, když vidím v Groovy 10. způsob zápisu volání metody a musím nad tím přemýšlet a uvědomit si, že tohle je také volání metody.

3565

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

« kdy: 31. 01. 2018, 21:07:30 »

Ale jo, použitelné je kde co. Třeba jehličí místo lopuchu. Ale zrovna srovnání IntelliJ Idea a Visual Studia je jednoznačně ve prospěch Idey, i když VS je použitelné, možná i docela slušně použitelné.

3566

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

« kdy: 31. 01. 2018, 20:31:28 »

spickove IDE ala Visual Studio tu je uz dlho

A proto existuje ReSharper, aby se to špičkové Visual Studio alespoň přiblížilo IntelliJ Idea? Mimochodem, IntelliJ Idea se „vynořila“ už v roce 2001, to možná někteří zdejší diskutující ani nebyli na světě…

3567

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

« kdy: 31. 01. 2018, 17:42:33 »

_{2. Nepodporuje kovariantní návratové typy, to jsem vcelku čuměl, nemůžu odělat override metody a vrátit potomka návratového typu. To je dost velký problém, jak mám udělat abstraktní oop návrh když tohle nejde.}
Ale podporuje, to co si napisal je polymorfizmus, vies vratit potomka. Ak myslis kovariantne a intravariantne genericke typy, tak tie sa v generiksoch definuju pomocou Foo<in T>, Foo<out T>.

Ne, to co popsal, jsou skutečně kovariantní návratové typy. Nejde o to, že metoda vrací instanci potomka, ale o to, že metoda na zděděné třídě deklaruje, že bude vždy vracet potomka. Takhle:

Kód: [Vybrat]

class Mlade {
}

class Stene extends Mlade {
}

class Samice{
  Mlade porod() {return null;};
}

class Fena extends Matka {
  @Override
  Stene porod() {return null;};
  //tohle bez kovariantních návratových typů nejde, bez nich musí být návratový typ překryté metody shodný s návratovým typem překrývané metody
}

Kontrakt předka je zachován, ale když někde použijete přímo třídu potomka, máte přesnější definici návratového typu.

3568

Distribuce / Re:Automatické spuštění skriptu při bootu

« kdy: 30. 01. 2018, 12:05:37 »

Docital som sa, ze script by mal mat

init script header

Skript ano. Vy ale nevytváříte skript, nýbrž jednotkový soubor (unit file).

Kód: [Vybrat]

update-rc.d: error: script Default-Start contains no runlevels, aborting.

Tohle s tím vaším jednotkovým souborem pravděpodobně nijak nesouvisí. Nemáte zapomenuté něco v /etc/init.d?

Docital som sa, ze script by mal mat init script header, pri tom init je pre lagecy soft, pokial zatial dobre chapem... No v kazom pripade, ci tam ten " init script header" je alebo nie je, je stav rovnaky...

Ano, dříve se pro start služeb používaly shellové skripty, systemd to nahradil deklarativním popisem služby v jednotkových souborech. Debian má k systemd přidané nějaké vlastní udělátko update-rc.d, které se pokouší do systemd integrovat i staré skripty v /etc/init.d – a k té vaší chybě dochází tehdy, pokud v tom /etc/init.d je nějaký chybný skript.

3569

Distribuce / Re:Automatické spuštění skriptu při bootu

« kdy: 29. 01. 2018, 17:06:16 »

Nejake rady, ako dalej?

Nevymýšlet si do unit file žádné !/bin/sh. To v žádném z těch návodů určitě nebylo. Stejně jako v těch návodech unit file neměly příponu .sh, protože to nejsou shellové skripty, ale měly příponu .service, protože jsou to jednotkové soubory popisující službu.

3570

Distribuce / Re:Automaticke spustenie scriptu pri starte PC

« kdy: 29. 01. 2018, 11:23:08 »

Debian 9 pokud vím používá systemd, to, co popisujete, by fungovalo s RC skripty a SysVinitem. Každopádně z takového skriptu nedostanete žádný výstup na konzolu, init skripty se spouští odpojené od konzole.

Popis, jak si v systemd vytvořit vlastní jednotku, najdete třeba zde: Writing unit files. Nebo krátký příklad zde: How to create a custom service that will autostart on boot on Archlinux? Obojí je shodou okolností pro ArchLinux, ale v Debianu to je stejné.

Výstup vašeho skriptu pak najdete v journalu (příkaz journalctl) – systemd tam přesměruje standardní výstup spouštěné aplikace.