Příspěvky

721

Hardware / Re:WoT == FLASH?

« kdy: 02. 04. 2015, 12:57:40 »

... Pořád jsem ale přesvědčen, že jádro hry a engine bude normální C++ - tj. od chvíle, kdy se začne bojovat do odchodu do garáže, s výjimkou těch 2D záležitostí.

No, a k cemu to je, ze je jadro v C++, pokud se opravdu na kazdem framu ceka na Flash vykreslujici "jen 2D zalezitosti", ktery bezi pouze v jednom vlaknu striktne na CPU?

Co jsem cetl, tak i ostatni MMO to prasi, treba Tera - bary nad postavami se vykresluji Flashem, UI je take Flash, po tomto "vylepseni" hodne hracu skoncilo. A popravde nechapu, proc to udelali - usetrena trocha casu vyvojarum versus odchod desitky(?) procent hracu (a citelne snizeni mnoziny potencialnich hracu). Zrovna u MMO bych cekal, ze je snaha, aby to jelo na kazdem "potato pc".

722

Hardware / Re:Notebook pro World of Tanks

« kdy: 31. 03. 2015, 20:03:18 »

... Totiz mnoho inych hier a programov nie je ako WoT a velmi rado vyuzije tych jadier viac.

Vetsina her, co proklamuje ze vyuziva vice jader, stejne zbyla jadra jen hodne nejiste pritopuje - maloco pouziva vice nez tretinu "ne-hlavniho" jadra (alespon tomu je tak na mem starickem phenomu). Co jsem nekde videl post primo od vyvojare nejakeho velkeho titulu, tak vyslovne psal, ze ve hrach, tj. aplikaci s kritickym jak vykonem tak odezvou, je velmi obtizne efektivne paralelizovat vypocty.

723

Studium a uplatnění / Re:Pracovní pohovor – vyžádání diplomu

« kdy: 16. 03. 2015, 11:09:18 »

U VŠ bych hodnotil poměr známka/námaha. Pokud se člověk dokáže na předmět, který ho nebaví, naučit za den na trojku tak je přece lepší a použitelnější než ten, co se učí týden na jedničku. 

Urcite by to bylo moudrejsi. Bohuzel si nedovedu predstavit, jak by zamestnavatel meril, co a jak moc studenta bavi a hlavne co se opravdu musel naucit. Pokud to totiz umel uz pred zapisem daneho predmetu, tak se nemeri schopnost naucit se.

Musim po pravde rict (i pres to, ze se mi to nelibi), ze si myslim, ze pro zamestnavatele je uzitecnejsi dost spatny student, ktery u skoly pracoval, nez velmi dobry student, ktery u skoly nepracoval (nebo jen velmi malo). "Lopaty" vetsinou z toho rozhledu tezi minimalne* a specialisty pouzitelne v praxi skola neudela (ano, muze ukazat cestu, ale je stejne na studentovi, aby si opatril praxi, tuny praxe).

* Nic proti "lopatam", asi se ji taky stanu. Prestoze dost temat je na VS zajimava, tak nemam iluze o tom, ze v praxi se s nimi nikdy nepotkam (pripadne je nikdy nebudu muset resit, protoze na to vse jsou uz vypilovane knihovny).

724

Studium a uplatnění / Re:Pracovní pohovor – vyžádání diplomu

« kdy: 16. 03. 2015, 10:11:13 »

...Zažil jsem i firmy, kde trvali na to, že v průbehu VŠ nesměla být ani jedna trojka. Ale je faktem, že to bylo na pozice jiného charakteru než je standartní programátorská monkey-work.

To jako ze ta firma potrebovala dobre zvladnuti vsech predmetu z dane IT VS? To by me hodne zajimalo, o jakou praci ze slo... Moc si nedovedu predstavit tu pozici. Je vyzadovano dobre zvladnuti Prologu, Assembleru, zaklady LaTeXu, teorie informace, komprese a kodovani, sifrovani, zabezpeceni, navrh sitoveho protokolu, navrh db, navrh prekladace, neuronove site, geneticke algoritmy, C++, Java, teorie her, historie vedy a techniky, pravni minimum, architektura procesoru a kopa dalsiho.

To mi hodne pripomina ty inzeraty psane HR, kdy hledaji dokonaleho zamestance pracujiciho za pet lidi ovsem za plat jednoho. IMO je vyhodnejsi se specializovat na jednu oblast, ne umet vsechno a nic. VS dava prave hlavne ten rozhled, moznost zvoleni specializace je casto pouze mala nebo nekdy dokonce uplne chybi.

725

Vývoj / Re:Java - get/set prefixy u metod

« kdy: 13. 03. 2015, 21:03:29 »

Napr. ve Scale je to, co popisujete, celkem bezna vec. V Jave psat immutable tridy je za trest (mam pocit, ze je to planovane do budoucna, netusim ale v jakem je to stavu). V jinem vlaknu jsem nedavno posilal nekolik moznych pristupu k immutable tridam v Jave vcetne srovnani se Scalou. A treba ta generovana copy metoda ve spojeni s nepovinnymi parametry usetri opravdu hodne boiler-plate kodu, nebo treba uvadet fieldy pouze jednou v konstruktoru, ne na vice mistech jako v Jave. Ale je mozne, ze nepisi dostatecne "OOP stylem" a neodpovidam tedy uplne na otazku.

726

Software / Re:Šifrovaný komunikátor bez historie

« kdy: 13. 03. 2015, 15:11:57 »

Neměl by někdo typ na komunikační klient / kecálek (podoně jako jabber, icq, skype), který NEukádá hesla v plain textu

IMHO nelze (leda kdybys neukládal hesla vůbec a ptal ses při každém připojení).

Neukladat hesla v plaintextu neni snad takovy problem, ne? Jeden xor s pevnym klicem navic. Sice to bezpecnosti neprida, ale podminku to splnuje (je tedy otazka, jestli neni podminka spatne formulovana).

Celkem me zaujal pozadavek na neukladani uzivatelskeho jmena. To slysim prvne. Vetsinou to naopak uzivatelum hodne schazi.

Nebylo by jednodussi si priohnout nejakeho Jabber klienta (vyhazet vsechna ta ukladani historie/hesel/jmen) a/nebo provozovat ho v nejakem sifrovanem kontejneru (heslo, historie i jmeno tak bude sifrovane)?

727

Software / Re:Šifrovaný komunikátor bez historie

« kdy: 13. 03. 2015, 14:56:24 »

Ze stranek to pusobi, ze GUI ma byt velmi jednoduche - tj. asi nebude obsahovat zadne pokrocile moznosti. Moc nevidim duvod, proc by pokrocilejsi uzivatele mel takovy program zajimat, pokud nic nepujde nastavit a bude skoro vse skryto. To stejne pro programatora - pokud se jede na ultimatni jednoduchost pro kazdeho bfu, tak asi mu zadne pull requesty pridavajici pokrocilejsi ficury nevemou.

A jaké pokročilé možnosti by tam měli být ? Nastavení fontu, vzhledu, profilu, databáze smajlíků ? To zrovna nehledam. Důležitá je bezpečnost. Tedy šifrování to end, aby nemohl prostředník odposlouchávat, aby senemohla textová komunikace uládat na server. A nejlépe aby se neukládala historie a hesla.

Pod pokrocilymi moznostmi jsem si predstavoval napr. nastaveni parametru sifrovani (napr. co jeste u druhe strany tolerovat a co uz ne [treba u SSL a myslim i u mobilniho sifrovani jsou mozne utoky s vnucenim slabych sifer]).

Protoze to ma byt co nejvice bfu-friendly, tak bych moc necekal striktni neukladani hesel u klienta nebo historie. IMO to bude dost lidi vyzadovat.

(Jenda me predbehl.) Kdyz je takto vice klientu, tak to bych uz vubec necekal, ze vsichni klienti nebudou ukladat hesla ani historii.

Kdyz by v pekarne byla reklama na rohlik a jako hlavni tahak by byla prezentovana vlastnost - "nemusite byt ani pekar, abyste ho mohli snist", tak by vam to pripadalo normalni?

Chcel by som mat tvoje problemy. text na stranke je to posledne podla coho by som hodnotil program...

Je to tak isto hlupe ako si nekupovat rohliky od pekara, pretoze sa ti nepaci font, akym su napisane jeho otvaracie hodiny.

Me osobne takovy text odrazuje. Jedna z hlavnich vlastnosti programu je, ze neni potreba byt programator (= zivit se programovanim), prestoze obecne pro pouzivani IM a sifrovani to nikdy potreba nebylo v prve rade. Pusobi to lzive (prestoze technicky to asi lez neni).

Podle vas je to stejne, jako nevolit stranu podle toho, co deklaruje ze planuje plnit. Vidim, ze si rozumime. Precejen kdyz maji na strance, ze to je pro BFU, tak mam ocekavat, ze to nebude pro BFU... Stranka ma presvedcit uzivatele ke stazeni a vyzkouseni.

728

Software / Re:Šifrovaný komunikátor bez historie

« kdy: 13. 03. 2015, 13:04:37 »

prave ze lojza by treba chtel sifrovat, ale mysli si ze musi byt programator nebo lepe ten hacker, tedy na tom textu nevidim nic trapneho... neni to cilene na power usery ale na bfu, pokud se to rozsiri mezi bfu ma to +- vyhrano...

Kdyz by v pekarne byla reklama na rohlik a jako hlavni tahak by byla prezentovana vlastnost - "nemusite byt ani pekar, abyste ho mohli snist", tak by vam to pripadalo normalni?

prave ze lojza by treba chtel sifrovat, ale mysli si ze musi byt programator nebo lepe ten hacker, tedy na tom textu nevidim nic trapneho... neni to cilene na power usery ale na bfu, pokud se to rozsiri mezi bfu ma to +- vyhrano...

Přesně tak, ten text naprosto jasně reprezentuje ten program. Na druhou stranu je to otevřené, takže i pepík, který naopak programator je, se na tom může vyřádit. Je to zkrátka pro všechny. Ukažte mi nějakej lepší program v dnešní době, kterej by se dal snadno použít a zároveň byl i pro lidi, co se v tom chtěj vrtat.

Tox má hned po instalaci jednoduché rozhraní, díky kterému se můžete radši věnovat tomu, s kým mluvíte.

Ze stranek to pusobi, ze GUI ma byt velmi jednoduche - tj. asi nebude obsahovat zadne pokrocile moznosti. Moc nevidim duvod, proc by pokrocilejsi uzivatele mel takovy program zajimat, pokud nic nepujde nastavit a bude skoro vse skryto. To stejne pro programatora - pokud se jede na ultimatni jednoduchost pro kazdeho bfu, tak asi mu zadne pull requesty pridavajici pokrocilejsi ficury nevemou.

729

Software / Re:Šifrovaný komunikátor bez historie

« kdy: 12. 03. 2015, 20:03:37 »

https://tox.im/cs

možná...

No nevim, ta stranka vypada moderne, ale ten text...

Tox po Vás nevyžaduje abyste byli programátoři když jej chcete používat.

To by me zajimalo, u jakych IM aplikaci je vyzadovano byt programatorem. Chapu, ze pro nastaveni nekterych kecalku mohou byt potreba znalosti z oblasti kryptografie, pokud to chcete mit trosku zabezpecene (coz vetsinou bezny lojza stejne neresi a necha vychozi hodnoty, ktere budou fungovat), ale vyzadovat byt programatorem? Ten text na me pusobi hodne trapne...

730

Studium a uplatnění / Re:C# .NET vs. Java?

« kdy: 01. 03. 2015, 15:26:27 »

V daném případě můžeš vyhodit obě třídy. Nic nedělají a jsou k ničemu. Tím ušetříš nejvíc psaní.

Nesou data, to je podstata immutable trid. Vzhledem k tomu, jak Java pridava funkcionalni rysy, cekal bych, ze pujdou i k necemu vyuzivat.

Pokud nesou jenom data, tak to nejsou objekty, ale struktury.

Jak presne se v Jave zapisuji struktury? Navic ta Scala implementace umi i copy metodu, tj. napr. Foo(1,2,"a").copy(name="b") vrati novou immutable instanci Foo(1,2,"b"), to si nejsem jisty, ze v Jave lze ani manualne napodobit (mozna neco jednodussiho ve stylu Foo(1,2,"a").updatedName("b")). Odpoved podle vas je tedy nepouzivat zadne postupy z funkcionalniho programovani?

To se používá jen u messengerů. Co takhle vypustit gettery a fieldy ponechat private?

U verejneho API? Ehm, to jako vratim tweet instanci s privatnimi fieldy, at si to klientska aplikace reflexi precte? Asi se nechapeme.

Proč? Klient přece nemá co hrabat na atributy objektu. Má být zapouzřený.

  Klient (napr. moje stranka) si zazada o tweet uzitim nejake knihovny, dostane tweet instanci a jak z ni vybali ty privatni data bez getteru? Nebo jako tweet trida z knihovny treti strany se bude umet zobrazit v me aplikaci? Co si znovu ctu vase odpovedi, tak to na mne pusobi, ze neexistuje spravna cesta. Datove objekty nemam pouzit, accessory take ne, mam pouzivat pouze privatni fieldy. Jsem z toho hodne zmateny. Mohu poprosit o vysvetleni na urovni zacatecnika?

731

Studium a uplatnění / Re:C# .NET vs. Java?

« kdy: 01. 03. 2015, 14:34:42 »

Celkove psat v Jave immutable tridy je za trest. Co jsem vygooglil, tak se to standardne dela hromadou accessoru.
... CODE ...
Neprijde mi o moc lepsi.

V daném případě můžeš vyhodit obě třídy. Nic nedělají a jsou k ničemu. Tím ušetříš nejvíc psaní.

Nesou data, to je podstata immutable trid. Vzhledem k tomu, jak Java pridava funkcionalni rysy, cekal bych, ze pujdou i k necemu vyuzivat.

Posledni co me napada je uplne vypustit gettery a prejit na verejne final fieldy. Co ctu, tak to ale moc Java-like neni (a u verejnych API uz vubec ne).

To se používá jen u messengerů. Co takhle vypustit gettery a fieldy ponechat private?

U verejneho API? Ehm, to jako vratim tweet instanci s privatnimi fieldy, at si to klientska aplikace reflexi precte? Asi se nechapeme.

732

Studium a uplatnění / Re:C# .NET vs. Java?

« kdy: 01. 03. 2015, 14:17:05 »

Psat acessory rucne neni potreba, zvlada to generovat IDE.

Psát accessory není vůbec potřeba. Stačí umět používat privátní atributy.

To funguje jak presne? Napr. vystup z Twitter API, to jako dostanu objekt tweet s privatnimi fieldy a budu s nim delat co?

Celkove psat v Jave immutable tridy je za trest. Co jsem vygooglil, tak se to standardne dela hromadou accessoru.

Kód: [Vybrat]

public class Foo {
  private final int x, y;
  private final String name;

  public Foo(final int x, final int y, final String name){
    this.x = x;
    this.y = y;
    this.name = name;
  }

  public int getX(){
    return x;
  }

  public int getY(){
    return y;
  }

  public String getName(){
    return name;
  }
}

Pak jsem nasel jeste jednu moznost, nevim jestli se pouziva (pripomina closures).

Kód: [Vybrat]

public interface Foo2 {
  int getX();
  int getY();
  String getName();
}

public class Foo2Creator {
  public static Foo2 create(final int x, final int y, final String name){
    return new Foo2(){
      public int getX(){
        return x;
      }

      public int getY(){
        return y;
      }

      public String getName(){
        return name;
      }
    };
  }
}

Neprijde mi o moc lepsi.

Posledni co me napada je uplne vypustit gettery a prejit na verejne final fieldy. Co ctu, tak to ale moc Java-like neni (a u verejnych API uz vubec ne).

Priklad reseni ve Scale:

Kód: [Vybrat]

case class Foo3(x: Int, y: Int, name: String)

Krome strucnosti dostanu navic oproti Jave porovnani, hash, extraktor (coz ale v Java svete asi moc nepouziju) a predevsim copy metodu.

Samozrejme je vice nez pravdepodobne, ze existuje nejaky lepsi pristup, precejen se Javou (ani Scalou) nezivim.

733

Studium a uplatnění / Re:C# .NET vs. Java?

« kdy: 01. 03. 2015, 12:48:07 »

Lombok jsem kdysi davno zkousel pri vyvoji modu pro Minecraft. Ale bylo s tim hromada problemu - pri MC modovani (Forge/FML + MCP) se totiz hodne upravuji vysledne zkompilovane tridy (jak staticky tak za behu) a nektere nastroje s tim mely problemy. Take nutnost pluginu do IDE pro vyuzivani knihovny neni idealni. Navic je to stale knihovna, neni to soucast jazyka - musi se distribuovat s vyslednou aplikaci. Co ctu, tak to pouziva pri kompilaci nejake hacky a funguje to jen na specifickem kompilatoru Javy...

734

Studium a uplatnění / Re:C# .NET vs. Java?

« kdy: 28. 02. 2015, 22:46:04 »

...Slušná pro jednoduchý kód. Bohužel se obě IDE chovají jinak než kompilátor...

Nemohu nez nesouhlasit. Nevyuzivam nejake moc pokrocile veci, ale uz se spray json jsem narazil. "Vyresil" jsem to presunutim problemoveho kodu do samostanych traitu v jinem souboru.

Ale tohle vse myslim souvisi s makry kompilatoru, coz zase v jinych jazycich casto vubec neni. Pomoci nich mohou vznikat knihovny, ktere v podstate spolupracuji s kompilatorem, takze napr. mohou omezit redundantni kod.

Miluju ty nové bastly, které umožňují všechno, ale nikdo v tom nic nedělá, protože to nejde. To stejné Python. Ten uměl všechny cool věci dávno, ale na velké věci nepoužitelný. Dodnes nechápu, proč si třeba vybrat Python před Javou nebo C#.

Pokud mluvite o Scale, tak moc nova neni 2003 - jen o 3 roky mladsi nez C#. A i velke projekty (i pres vyse zminene problemy) se bezne pisi ve Scale. Napr. Hootsuite prechodem z PHP na Scalu (Akka a Play) usetril naklady za provoz 80% serveru. Mam pocit, ze Twitter se Scalou take neco delal, ale nepamatuji si detaily.

Z tech par zbastlenych skriptu v Pythonu to na me take pusobi, ze je spise na mensi veci. A prestoze funkcionalni ficury ma, tak jejich pouziti se mi casto zda dost neohrabane.

... obecně, už to dříve bylo napsáno, ale zopakuju - fakt, že můžu někde napsat o znak nebo o řádek míň, opravdu neznamená, že je daný jazyk lepší, často je to spíš naopak, protože tím často trpí čitelnost!

Mit ale stale se opakujici radky kodu, ktere nejsou vyznamove taky, k nicemu neni. Kupr. trivialni gettery/settery v Jave by nemusely byt na tolik radku.

Kód: [Vybrat]

public int getFoo(){
  return foo;
}

// vs

def foo = _foo

Zadnou pridanou hodnotu v Java verzi nepozoruji.
Podobne jako bylo drive otresne prochazeni poli/mnozin - nekolik vnorenych cyklu, treba na deset radek (pochopitelne polovina jsou zavorky a tretina trivialni iterace nad kolekci/polem). Stejne tak jako nutnost uvadet typ, klidne na pul radku, u lokalnich promennych na miste, kde je rovnou instancujeme - tj. redundance, typ nalevo i napravo zavorky, zadnout informaci ani citelnost navic to neprinasi (metody ve Scale se doporucuji delat velmi kratke, idealne par radku).

735

Studium a uplatnění / Re:C# .NET vs. Java?

« kdy: 28. 02. 2015, 20:19:55 »

S tim prasenim na tom Scala bude podobne. IMO prasit se da vsude, akorat v hodne vystiznych jazycich bude vyssi pomer prasecin na znak, coz je ale dano pouze tim, ze tyto jazyky jsou vystizne (i dobry kod bude kratsi a strucnejsi). Narozdil od Groovy* je ale Scala staticky typovana a podpora v IDE je slusna (Eclipse a predevsim IntelliJ IDEA).

Scala ma mnohem pokrocilejsi type inference nez C#, nekde drive v tomto vlaknu jsem i uvadel priklad (v porovnani s Groovy netusim). Uz ted jsou v Jave nejake naznaky zestrucneni, tusim vynechavani typu u generik pri vytvareni instance? Mozna se dockame i trochu pokrocilejsi verze.

* Jsem si celkem jisty, ze Groovy podporuje staticke typy uz nejaky cas (clanek z 2012). V nekterych pripadech neni prakticky zadne zpomaleni oproti Jave.