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 - registrovany_ava

Stran: [1] 2 3 ... 8
1
Respekt (ale trochu nerad, zajímavých článků tam tolik není, ale aspoň se trochu udržuju v obraze), 7. generace, Babylon (obojí super)

2
Software / Re:Todo list system
« kdy: 27. 03. 2021, 08:31:30 »
textak typu:

otvorit root.cz [X]
najst zaujimavy prispevok [X]
odpisat [X]
precitat si komentare na moju odpoved [   ]

To se právě dá na gitlabu, akorát se to píše

Nezapomenout na root

 -  [X] otvorit root.cz
 -  [X] najst zaujimavy prispevok
 -  [X] odpisat
 -  [   ] precitat si komentare na moju odpoved

a GitLab z toho vyrenderuje rozhraní s klikatelnými podtasky.

3
Software / Re:Todo list system
« kdy: 25. 03. 2021, 14:56:08 »
Gitlab issues

4
Vývoj / Re:Práce s vlákny v C
« kdy: 26. 01. 2021, 10:52:09 »
Volba slova “neotřelá” je velmi ohleduplná k tomu, kdo ten nesmysl o posílání loggeru vyřknul :)
Za prve: Kterou cast prispevku
Ježkovanoho, to je příklad. Jde o princip, ne o tuhle konkrétní věc. Nedokumentované struktury jsou všude možně, je to běžný pattern.
jsi nepochopil?

Za druhe: ne, neni to nijak zvlast neotrele. Pouzil jsem to jako priklad, protoze presne tohle mam v kodu pred sebou. Jsou tam nejake "objekty" (implementovane samozrejme strukturou), u kterych se nekde na zacatku kodu inicializuje logger. Ten se pak vlozi do struktury, aby si kazdy "objekt" mohl logovat tak, jak bylo na zacatku nastaveno.

Co je na tom "neotreleho"? A co je tak skandalniho na myslence, ze bych si chtel tenhle objekt nekam poslat channelem?

A vubec nejzasadnejsi otazka: proc tak urputne obhajujes neco, co zjevne ma svoje mouchy? Proc nemuzes proste priznat "jo, neni to idealni, slo by to udelat lip"? Ses ted jako placenej ambassador Go nebo jak?! Nechapu to. Pripominas mi javascriptare, kteri urputne obhajuji, jak je == v JS uplne v pohode a nema zadny problem.

 ::)

Jsem překvapen, ale zcela souhlasím s Mirkem. Pokud je to aspoň trochu praktické, naprosto preferuju compile-time safety před runtime asserty, unit testy, štábní kulturou, selským rozumem a podobnými věci, na které je ošemetné se spoléhat. V tomto smyslu je určitě Rust nebo Elixir napřed před Go.

5
Vývoj / Re:Práce s vlákny v C
« kdy: 26. 01. 2021, 10:48:18 »
Osobně jsem se základy práce s mutexy a podmínkovými proměnnými dočetl v tomto starodávném článku. Ten článek sice vyšel dávno před přechodem libpthread v Linuxu na NPTL, takže některé poznámky o interně používaných signálech apod. už neplatí - ale základní "o čem to je" platí myslím dál.

Ještě jsem si vzpomněl, že jsem možná první zmínku o libpthread a vláknech četl v papírovém vydání "Linux - začínáme programovat", někdy v roce 2000. A jak jsem při následném online studiu užasl, že v té knížce úplně vynechali podmínkové proměnné (conditional variables). A teď vidím online 4.vydání v PDF, a v kapitole 12 dodnes není ani zmínka o podmínkových proměnných :-) Ostuda. Listuju v papírové knížce a našel jsem jako záložku svůj papír, kde jsem si průchod dvou vláken "synchronizací s podmínkovou proměnnou" načmáral :-) A vytištěnou stránku z Linux Standards Base reference, která obsahuje seznam funkcí libpthread.

Klasické synchronizační vzory jsou výborně popsány ve free knize Little Book of Semaphores: https://greenteapress.com/wp/semaphores/ . Vždy jsem tam našel co jsem potřeboval.

6
Pro zajímavost, v Rustu se to dělá idiomaticky bez korutin i bez implementace vlastního iterátoru. Když už mám iterátor, a chci z něj jen vyfiltrovat některé položky, použiju prostě metodu filter, která vrací jiný iterátor. Ten má v sobě zabalený ten původní a predikát, při iteraci přeskakuje nevyhovující.

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=c93f0ee782a56a5e475f6e26c95229f3

fn filter_files(iter: impl Iterator<Item=String>) -> impl Iterator<Item=String> {
    iter.filter(|item| item.starts_with("Soubor"))
}

fn main() {
    let v = vec!["Soubor XXX".to_string(), "Adresar YYY".to_string()];
    for s in filter_files(v.into_iter()) {
        println!("{}", s)
    }
}


vypíše Soubor XXX.

Hej implementovať vlastný iterátor nemusíte, lebo ho už pred vami implemetovali programátri rustovského ekosystému. filter vracia špeciálny iterátor s názvom Filter ...

Jasně, vždyť přesně to můj příklad dělá :-) filter_files vrací Filter, akorát že ten Filter je tu maskovaný pod typem impl Iterator<Item=...>, abych se nemusel s tím typem vypisovat, a taky v budoucnu umožnil eventuelní změnu implementace bez narušení kompatibility typů funkce..

7
Pro zajímavost, v Rustu se to dělá idiomaticky bez korutin i bez implementace vlastního iterátoru. Když už mám iterátor, a chci z něj jen vyfiltrovat některé položky, použiju prostě metodu filter, která vrací jiný iterátor. Ten má v sobě zabalený ten původní a predikát, při iteraci přeskakuje nevyhovující.

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=c93f0ee782a56a5e475f6e26c95229f3

fn filter_files(iter: impl Iterator<Item=String>) -> impl Iterator<Item=String> {
    iter.filter(|item| item.starts_with("Soubor"))
}

fn main() {
    let v = vec!["Soubor XXX".to_string(), "Adresar YYY".to_string()];
    for s in filter_files(v.into_iter()) {
        println!("{}", s)
    }
}


vypíše Soubor XXX.

8
Vývoj / Re:BASH - echo "/!/"
« kdy: 02. 01. 2021, 11:43:42 »
Ok. A na čo to je dobre prakticky?

spustí ti to poslední příkaz z historie podle jeho začátku.
...

Doplňuji, že se často hodí vyhledávání v historii příkazů přes Ctrl-R.

9
Vývoj / Re:Trait a konstruktor
« kdy: 23. 12. 2020, 13:08:39 »
Dotty (Scala 3) podporuje parametrizované traity. (A také "intersection types", které mohou při práci s traity přijít vhod.)

Hmm, jaký pak zbývá rozdíl mezi trait a class kromě toho, že není možné dědit z více class najednou? Co by se stalo, kdyby se klíčové slovo class zrušilo a používaly se jen tyhle nové traity?

Nevím jak Dotty, ale základní rozdíl mezi dědičností a traity je v té dědičnosti. Když máš objekt O, do kterého přidáš trait T, tak ten objekt O není tím T. (Maximálně tak T obsahuje.) Zatímco když O dědí od předka P, tak O je P.

Jako asi pro tebe nic nového, ale tohle je prostě ten rozdíl 1. To je všechno.



1/ Tak maximálně ještě, že metody z traitu se obvykle nepřetěžují, že se s tím trochu jinak pracuje, a tak.

Mě to zajímá právě v Dotty, jestli tam mohou traity mít parametry při instanciaci, ptám se po rozdílu mezi trait a class, to byla tak poslední věc co class uměla a trait ne. Možná už to budou opravdu jen detaily - Java interop nebo tak, možná mi něco nedochází.

Ve Scale (i pre-Dotty) je totiž možné udělat tohle:

trait Foo {
    def hello(): Unit = {println("Hello, world")}
}

object Main {
    def useFoo(foo: Foo) {
        foo.hello()
    }

    def main(args: Array[String]) = {
        val foo = new Foo {};
        useFoo(foo)
    }
}

V tomhle kontextu mi přijde, že i tvé rozlišení v tom, že class znamená "být" a trait znamená "mít" se smývá, protože pokud něco jsem, tak to i mám, "mít" je silnější.

10
Vývoj / Re:Trait a konstruktor
« kdy: 22. 12. 2020, 09:53:45 »
Dotty (Scala 3) podporuje parametrizované traity. (A také "intersection types", které mohou při práci s traity přijít vhod.)

Hmm, jaký pak zbývá rozdíl mezi trait a class kromě toho, že není možné dědit z více class najednou? Co by se stalo, kdyby se klíčové slovo class zrušilo a používaly se jen tyhle nové traity?

11
Vývoj / Re:Trait a konstruktor
« kdy: 19. 12. 2020, 08:15:18 »
class C(val f: Integer) extends T {
  def printF(): Unit = {
    println(f)
  }
}
Tohle je docela hezký.

Jde nějak ještě když bych tomu chtěl přidat nějakou logiku? Tedy konstruktor přijme f, přepočítá ho, a teprve výsledek uloží do fieldu f?

Místo konstruktoru použiješ faktory metodu, typicky v associated objectu třídy.


trait T {
  def f: Integer
}

class C(val f: Integer) extends T {
  def printF(): Unit = {
    println(f)
  }
}

object C {
  def apply(s: String): C = {
    new C(s.toInt)
  }
}

object Main {
    def main(args: Array[String]): Unit = {
      C("11").printF()
    }
}

Ale taky mám radši composition over inheritance. Kdybych chtěl skládat tvůj UserAccount podle toho vzoru co ukazuješ, použil bych kompozici. I když by to ve Scale šlo poskládat z traitů s fieldy jak chceš, nelíbilo by se mi, že v definici UserAccount není jasně na jednom místě vidět, jaké fieldy nakonec v té třídě budou, člověk si musí projít všechny traity zvlášť, a přitom fieldy a jejich typy bývají pro porozumění kódu většinou to nejdůležitější.

12
Vývoj / Re:Trait a konstruktor
« kdy: 18. 12. 2020, 10:36:14 »
Jak psali přede mnou, Rustovské traity fieldy nemají, a nemám pocit, že by mi tam chyběly.

Scala je má, inicializují se přímo v definici traitu

trait T {
  val f: Integer = 1
}

class C extends T {
  def printF(): Unit = {
     println(f)
  }
}

Kdybych chtěl inicializaci odložit, tak z toho fieldu udělám abstraktní metodu, používá se to stejně jako field.

trait T {
  def f: Integer
}

class C(val f: Integer) extends T {
  def printF(): Unit = {
    println(f)
  }
}

13
/dev/null / Re:Aky kavovar pre dobru kavu?
« kdy: 10. 12. 2020, 08:38:20 »
No, nejsem na to expert, ale domácí presovače mi vždycky přišly jako pitomost. Smysl espressa je v tom udělat ho rychle (proto ten název), proto se stroje na výrobu espressa (mimochodem, ty co vidíš v kavárnách začínají někde na 200 000 Kč) tak rozšířily, můžeš zákazníkovi udělat dobrý kafe za 30 vteřin, s dvojpákou dvě najednou. Kdybych si chtěl udělat dobrý kafe doma, nebudu si pořizovat espressovač za desítky tisíc Kč, který stejně bude o řád horší než ten kavárenský, ale budu experimentovat s překapávanou kávou, džezvou, mokka kávou atp. Dají se z toho udělat stejně kvalitní a i zajímavější kávy než z presovače za řádově menší peníze, jen to prostě potrvá o minutu dýl (proto se to komerčně moc neuplatňuje), ale zas si s tím můžu hrát, a za ty ztracené minuty bych si na ten presovač stejně nevydělal.

Je to ovšem samozřejmě mimořádně subjektivní téma. I když jsem brigádně několik let dělal za barem a udělal tisíce káv, stejně radši piju čaj, a tein funguje stejně jako kofein :-)

14
Odkladiště / Re:Prodej Excel spreadsheetu
« kdy: 03. 12. 2020, 07:18:11 »
Tak ve statnim uz nikdo neumi ani v Excelu a tabulky si kupuji od part-time zamestnancu? Nepredpokladam, ze ta tabulka bude vyzadovat VBA backend, takze slecna mozna obarvi zahlavi a udela filtry. Nehlede na to, ze na evidenci uz by byla urcite vhodnejsi nejaka databaze.. Vam to nikomu neprijde divne? Rad bych se mylil, ale tudy se ztraci nase penize z dani  :)

Slečna narozdíl od tebe v tom výzkumáku pracuje, takže ví co a jak by tam bylo potřeba udělat. Ostatním děkujeme za příspěvky a rady.

15
Odkladiště / Prodej Excel spreadsheetu
« kdy: 02. 12. 2020, 14:41:30 »
Kamarádka se na mě obrátila s dotazem, obracím se na znalejší.

Pracuje na malý úvazek ve výzkumáku, kde nicméně příští rok nebude dost peněz na lidi, ale budou peníze na materiál (zní to bláznivě, ale není to k diskuzi). Napadlo ji, že by jako svůj přínos institutu, kde je docela platná a oblíbená, vytvořila spreadsheet, který by pomáhal s evidencí vzorků, a ten výzkumáku prodala za materiálové peníze, šéf by proti tomu asi nic neměl. Ráda by znala odpověď na dvě otázky, které možná zní naivně, ale zjistil jsem že na ně vlastně s jistotou nedovedu odpovědět.

1. Je možné prodávat .xls vyrobené v Excelu z Microsoft Office jen tak, samostatně, nejsou nějaké potíže např. s licencemi Office atp.?

2. Může to ona, nepodnikatel, obyčejná osoba, nějak výzkumáku prodat, nebo by si musela zařídit živnost, popř. to udělat přes prostředníka (což bych byl asi já, mám živnost na výrobu SW)? Jedná se o prodej v řádu nízkých desítek tisíc Kč.

Stran: [1] 2 3 ... 8