Poslední příspěvky

1

Vývoj / Re:Přechod z Javy na Rust. Ano či ne?

« Poslední příspěvek od balkovic kdy Dnes v 09:56:40 »

2/ většina jazyků lepší nástroj pro reusable kódu jak dědičnost nemá (Java), některé nemají dokonce ani rozhraní (C++) (Překvapivě takový odsuzovaný jazyk jako je PHP ano.)

Dovolím si polemizovať, java má aj lambdy a to je ďalšia možnosť prepoužitelnosti kódu. Potom sú rozhrania s default implementáciami metód, čo sú vlastne traits na javovský spôsob.

Já ti nevím. Lambdy jsou IMHO na něco jiného, a default implemetace metod tak nějak neřeší, že v jedné skupině adaptérů chci tuto implementaci a v druhé skupině jinou. Nemluvě o tom, že je to stále dědění. To je stejně blbě, jak se o tom bavíme.

Keď sa interfacy s default metódami dobre použijú, umožňujú spraviť kompozíciu miesto kitchensink dedenia. A tvrdenie, že funkcionálne programovanie neumožňuje znovupoužiteľnosť kódu, za to by ma prefackali.

2

Bazar / Outdoor cabinet 380V/230V PDU/AC/DC HVAC included

« Poslední příspěvek od Kampeak kdy Dnes v 09:54:40 »

Dobrý den,
Nabízím venkovní kabinet.

Cabinet empty-ASSY, EQUIPMENT CABINET (it does include several small components such like breakers, cables, …)
Cabinet (HVAC included), Dantherm (DC Air Conditioner 4000)VICD, HVAC, 4000BTU/HR COOLING CAP, 500W HEATER, 48VDC, VARIABLE SPEED COMPRESSOR AND FAN, CLOSED LOOP COOLING, 29.0X17.3X11.3IN, -40 T0 55C,UL/CUL/ROHS

V případě zájmu prosím se mi ozvěte
Skladem 150 KS

3

Vývoj / Re:Přechod z Javy na Rust. Ano či ne?

« Poslední příspěvek od Kit kdy Dnes v 09:48:49 »

Připadá mi to jako divočina, hlavně mi vadí pleonasmy. Proč má v tom svém "správném přístupu" 2× slovo "hnuj", když stačí jedno?
Vidle.naber(hnuj)
Vidle.naber(seno)

Souhlas. Pokud jazyk umožňuje přetěžování metod/funkcí  (např. Java ano, Céčko ne) tak tam nadbytečná slova taky nedávám. Líp se to čte a kód je kratší.

Nicméně v tom příkladu šlo o tu logiku, který objekt je aktivní a který pasivní a kde se nachází implementace. Jde třeba o různé ukládání nebo načítání – ať už do různých souborových formátů nebo třeba do databáze nebo odeslání na po síti. Ve většině případů považuji za špatný návrh to, aby ten datový objekt měl takovou metodu. Většinou patří spíš do jiného objektu, který se o de/serializaci příslušného formátu (PNG, XML atd.) nebo obsluhu příslušného úložiště a správu spojení stará. Je to pružnější návrh, který umožňuje přidávat další formáty a úložiště (i jiným autorům) a nezanáší to rozhraní toho objektu a nezvyšuje to komplexitu jeho implementace (v něm je jen metoda a kód pro vrácení nebo načtení nějaké kanonické implementace třeba RGB bitmapy, zatímco implementace jednotlivých kodeků je jinde).

Vezměme tvorbu JSON z objektu v PHP: Samotný převod dělám json_encode($objekt); tedy samotnou serializaci dělá vnější funkce, ale o přípravu dat se stará samotný objekt.

Těch rozhraní bude víc - je to popsáno v SOLID. V každém z nich bude tolik metod, kolik bude třeba - klidně i jen jedna. Dělám to tak a nejsou s tím problémy. Dokonce se ta rozhraní pojmenovávají mnohem snáze, než kdyby tam těch metod bylo víc.

Ta doporučení a principy je dobré znát, ale aplikovat je až příliš „nábožensky“ je někdy na škodu. Podobné je to s novějšími konstrukty jazyka (třeba lambdy od Javy 8 ). Kolikrát si napíšu více variant kódu a porovnávám je, přemýšlím nad tím z hlediska čitelnosti, budoucího rozvoje, výkonu… někdy z toho vyjde, že to „modernější“ nebo „správnější“ řešení slouží hůře, je méně užitečné, méně praktické. Podobně člověk někdy poruší normální formy při návrhu databáze.

Naopak mi připadá výhodné, když v záhlaví třídy mám "komentář" v podobě seznamu rozhraní, která musím implementovat.

Je dobré nad tím přemýšlet i z hlediska strukturování… v tom odkazovaném článku o komplexitě taky píšu:

Je možné, že už jsme blízko hranice dané inherentní složitostí a další zjednodušení už není bez změny zadání možné. V tomto případě si můžeme ještě trochu pomoci přeskupením prvků. Člověk není stroj a jeho kognitivní schopnosti mají svoje limity. Millerovo magické číslo nám říká, že člověk dokáže udržet v krátkodobé paměti maximálně 7±2 prvků. Počítači je celkem jedno, kolik má program tříd, kolik má třída metod, výčtový typ členů nebo komponenta parametrů. Počítač zvládne hravě vykreslit na obrazovku desítky ikon nebo vyhodnotit desítky CLI parametrů u jednoho příkazu. Počítač často škáluje lineárně a vypořádá se i s velmi vysokým počtem prvků. U člověka se to ale na určité hranici láme a schopnost porozumět systému a pracovat s ním prudce klesá. Platí to pro programátory upravující software i pro uživatele, kteří ho mají používat. Samotnou změnou struktury tedy můžeme lidem trochu pomoci vypořádat se s komplexitou.

Jinak řečeno: příliš mnoho rozhraní, tříd, metod, souborů atd. může lidem zhoršovat schopnost orientace a pomůže strukturovat program jinak. Příčí se mi sice napsat „když máte ve třídě příliš mnoho metod, tak to rozdělte do víc tříd“ nebo „když máte v adresáři příliš mnoho rozhraní tak je rozdělte do víc adresářů nebo spojte více rozhraní do jednoho“ ale ve výsledku to tak trochu je.

Pak jsou i jiné možnosti jak to navrhnout. Třeba to rozhraní posluchače událostí může mít jednu metodu přijmout(událost), do které budou chodit instance různých tříd nebo rozhraní a uvnitř té metody si pak vybereš, na co budeš reagovat. Ale to má zase jiná úskalí – kód bude méně přehledný (než u rozhraní s více metodami a Adapteru) a s dědičností/hierarchií/granularitou se sice nepotýkáme u rozhraní, ale u těch objektů reprezentujících události, takže jsme problém jen přesunuli jinam. Pro programátora-uživatele taky může být těžší dohledat, jaké všechny události mu tam můžou chodit (zatímco v jednom rozhraní vidí ty související metody vedle sebe – a až při případném rozšiřování rozhraní se udělá další, aby se nenarušila zpětná kompatibilita).

S tím také mohu souhlasit. Snažím se dělat návrh tak, aby počet metod byl kolem 5. Dobrou pomůckou je, že když pro název metody potřebuji víc než jen jedno slovo (sloveso), tak je možná něco špatně.

Zajímavou inspirací je v tomto ohledu formát RDF: subjekt.predikát(objekt).

4

Bazar / Re:Prodám Calibrite ColorChecker Studio

« Poslední příspěvek od Zrzka kdy Dnes v 09:01:19 »

No, protože mám jen tu sondu a kabel, nic dalšího, tak to dám za 1.500,- Kč. Ať to neskončí v šuplíku nebo v kontejneru.

5

Odkladiště / Re:Jak odpovědět na výhružný dopis od BSA?

« Poslední příspěvek od Marek Staněk kdy Dnes v 08:56:53 »

Envisional.com je registrovaný na subjekt Corporate Addresses, specializující se na "obálkové" firmy, tzn. dodají adresu sídla, telefonní číslo, eventuálně recepční službu. Velmi oblíbené u podvodných firem, které z nějakého důvodu potřebují funkční doručovací adresu a zvedat telefon.

6

Hardware / Re:Vyplatí se spotový elektroměr a server

« Poslední příspěvek od jjrsk kdy Dnes v 08:53:16 »

...
Myslíte, že by se spotový elektroměr vyplatil, lze to?

Uz jen vygenerovanim tohodle hloupyho dotazu si promrhal mnohem vic nez tech 5 piv mesicne co te to stoji ...

7

Vývoj / Re:Přechod z Javy na Rust. Ano či ne?

« Poslední příspěvek od Jožka Niemand kdy Dnes v 08:51:57 »

Nicméně v tom příkladu šlo o tu logiku, který objekt je aktivní a který pasivní a kde se nachází implementace. Jde třeba o různé ukládání nebo načítání – ať už do různých souborových formátů nebo třeba do databáze nebo odeslání na po síti. Ve většině případů považuji za špatný návrh to, aby ten datový objekt měl takovou metodu. Většinou patří spíš do jiného objektu, který se o de/serializaci příslušného formátu (PNG, XML atd.) nebo obsluhu příslušného úložiště a správu spojení stará. Je to pružnější návrh, který umožňuje přidávat další formáty a úložiště (i jiným autorům) a nezanáší to rozhraní toho objektu a nezvyšuje to komplexitu jeho implementace (v něm je jen metoda a kód pro vrácení nebo načtení nějaké kanonické implementace třeba RGB bitmapy, zatímco implementace jednotlivých kodeků je jinde).

To ale nejde takto kategoricky, bez kontextu říci. A to je přesně to, o čem jsem mluvil - past zkušenosti "reálného světa", "selský rozum". Jenže ten občas selhává. Tento selský rozum by nám velel, že např. v nějakém GUI je nějaký painter, který zajišťuje zobrazování jednotlivých oken (jako Screen.paint(window)) - a opravdu tak něco takového může být. Ale z praktického hlediska window rozumí nějaké zprávě typu drawOn, kterou nakonec zpětně pošle ten painter tomu oknu, protože ono nejlépe ví, jak se namalovat - tedy nakresli se - což je to "zvěrstvo" typu naskoč si na vidle. Naopak, lpění na modelu z reálného světa by představovalo komplikaci.

8

Hardware / Re:Vyplatí se spotový elektroměr a server

« Poslední příspěvek od martius. kdy Dnes v 08:32:27 »

Bydlím v paneláku, uvažuji do budoucna o namontování spotového elektroměru, účet za elektřinu je asi 2.300 Kč přičemž z toho 1.000 Kč měsíčně dělá server, ročně tedy cca. 30.000 Kč. Furt uvažuji o spotovém elektroměru, jestli by se nevyplatil, moje úvaha je, že moje chytrá domácnost a server má velkou část spotřeby mimo špičku, kdy elektřina je skoro zadarmo (jedou soláry, vítr), pak v noci, tipl bych si, že půlka elektřiny je 24x7, a pak samozřejmě špička, večer atd., televize, vaření atd...

Myslíte, že by se spotový elektroměr vyplatil, lze to?

Je možné, že provozovatel sítě už plánuje změnu Vašeho elektroměru - doporučuji se zeptat podle místa odběru na EGD / ĆEZ / PRE.

Jsem konkrétně v oblasti, kde "panuje" :-) EGD. Z minulého týdne mám zprávu, že do 3 měsíců vymění elektroměr za chytrý...

A druhé doporučení, v souladu s předřečníky: oslovit více obchodníků s energií. Nejlepší cenu jsem našel u Skautské energie, cenově není špatný ani Tedom (OBCHODNÍ složka bez distribuce kolem 2850 - 3050 Kč/ MWh).

9

Vývoj / Re:Přechod z Javy na Rust. Ano či ne?

« Poslední příspěvek od Jiří Havel kdy Dnes v 08:23:21 »

Jinak ono na ten nepočítačový svět nejlépe pasuje z těch programátorských paradigmat právě to objektové (neplést nutně s dědičností), protože i objekty v tom nepočítačovém světě mají nějaký stav a nějaké chování. Fyzické objekty nikdy nejsou „immutable“ (i když by si to vyznavači funkcionální víry přáli :-). Ty objekty mají stav, který se v čase mění. Většinou mají i nějaké (pozorovatelné, zajímavé) chování, naopak bezstavových funkcí nebo procedur je v nepočítačovém světě minimum, pokud vůbec...

Je celkem jedno, jestli fyzické objekty mají nějaký stav co se v čase mění. Důležité je, jestli tu změnu stavu opravdu potřebuju reprezentovat. Jestli pak ten stav není spíš kontraproduktivní, protože třeba jenom zavazí při paralelizaci.

Například je rozdíl jestli opravdu potřebuju modelovat detailní strukturu jablka a to jak si v čase vyměňuje molekuly s okolím. Nebo jenom počítám jablka jako pasivní a neměnné věci. Drtivou většinu stavu a chování objektů okolo nás obvykle zanedbáme dávno předtím, než přijde na řadu nějaké programování.

10

Hardware / Re:Rozdílné barvy na monitorech Dell a Mac

« Poslední příspěvek od registrovany123 kdy Dnes v 08:05:56 »

Nevím jestli ta relativizace barev dle přepínání profilů není trochu přehnaná, já používám jako referenční monitor Macbook Air a Pro. To žádné profily pro zobrazení nemá, a zobrazuje to barvy pěkně. Na tom Dellu bych nezvolil jiný grafický profil než-li "Standard", protože nic z těch dalších mi nedává smysl.

Smysl to má snad leda pro usera, který si nějaký ten "hloupý" (mě přijdou hloupé) grafický profil vybere.

Protože dělám Internetový web, tak tam se mi vyplatí barvy nastavit dobře, už jenom proto, že hodně lidí ma Macy, nebo i iPhone a některé Android displaye jsou kvalitní a tu barvu zobrazí rovněž. A za 20 let, co ten web poběží, tak si spousta userů koupí nový monitor a barvy třeba uvidí.