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 - Zabanovaný Anonymní Troll

Stran: 1 ... 5 6 [7] 8 9 ... 31
91
Vývoj / Re:Dalsi, UZ POSLEDNI KIKS V PYTHONU
« kdy: 01. 04. 2020, 12:22:17 »
JSON zachovava poradi klicu, a proto kdyz mam knihovnu ktera deserializuje JSON, tak to MUSI TA KNIHOVNA ctit.

Kam na ty nesmysly chodíš? Co takhle si přečíst třeba JSON standard?

An object is an unordered set of name/value pairs.

No tak jsem se spletl no, my v Jave mame json odjakziva ordered, nikdo neni zvedavy na to aby se mu v logach prehazovala poradi atributu 8)

92
Vývoj / Re:Dalsi, UZ POSLEDNI KIKS V PYTHONU
« kdy: 01. 04. 2020, 11:34:37 »
Dictionary v Pythonu nezachovava order klicu!!!
Zatímco Map v Javě – nezachovává pořadí klíčů. Jak překvapivé. Ona to je totiž režie navíc, přitom u většiny způsobů použití mapy/slovníku zachovávat pořadí klíčů nepotřebujete.

My v Jave mame i svoje vlastni objektove databaze, ktere ale moc nepouzivame, protoze jsou Java-specific. Pouzivame univerzalnejsi SQL databaze, ktere sice vyzaduji ORM vrstvu a dalsi opruzy, ale zato jsou standardni. Jiank bychom si v Jave taky mohli ukladat objekty a pracovat s nima bez nejakeho ORM.
Pokud to nebyl pluralis majestatis, pište sám za sebe. Spousta věcí, co píšete, nemá nic společného s tím, co je programátory v Javě obecně přijímané.

1. Map v Jave je interface, a kdyz do ni das LinkedHashMap, coz ti udela Jackson, tak to mas ordered. To bys mohl vedet.
JSON zachovava poradi klicu, a proto kdyz mam knihovnu ktera deserializuje JSON, tak to MUSI TA KNIHOVNA ctit.

2. 90% pripadu vyvoje nejake komplexnejsi service je klasicka Databazove orientovana komponenta, porad dokolecka, uz poslednich 20 let prinejmensim. Nejvice skody vznika akorat tim, ze to programatori porad nejsou schopni pochopit a snazi se delat jakesik custom reseni a akorat to dojebou.

93
Vývoj / Re:Dalsi kiks v Pythonu!!!
« kdy: 01. 04. 2020, 02:32:33 »
1) Frajer mozna, zkuseny programator se tomu instinktivne vyhyba, protoze je to AntiPattern: https://www.zdrojak.cz/clanky/orm-je-antipattern/ Jestli bez ORM neumis napsat nezabordeleny kod, tvu jproblem.
2) DRY a KISS se vztahuje k dedicnosti a intrfacum, kdy nevyhodu vydavas za vyhodu. Aniz bych posuzoval tu knihovnu a snazil se rozklicovat, zda je chyba v tobe nebo v ni, knihovna neni Python. Jdes na vsechno desne blbe blbe.

"Zkuseny" skripter v Ruby se tak mozna ORM vyhyba. V celem tom clanku neni jedina zminka treba o tom, jak ti Hibernate pomaha zajistit, aby instance modelovych trid byly thread safe, coz je extremne dulezita vec, kterou kdyz si musis zajistovat sam, tak je to totalni opruz.

Vy totiz v Pythonu (a dalsich skriptovacich jazycich) nemate ORM udelane tak poradne, jako my v Jave, a to je je ten problem tohoto vyplakavani.

ORM navic neni berlicka pro blbecky co neumi ani SQL. ORM je pro zkusene programatory. Hibernate drasticky redukuje mnozstvi kodu a bordelu v aplikaci.

Dalsi nonsense v tom clanku je zpochybnovani relacnich databazi. Relacni databaze predstavuje 1:1 (!!!) vztah mezi objekty v OO jazyce a podobou jejich perzistence (narozdil od NoSQL, ktera tento vztah NEZACHOVAVA). ORM je KISS pro praci s objekty.

To, ze si u ORM delam i svoje SQL dotazy, neni nic proti nicemu. Vseobecne jedna se o clanek napsany beztak nejakym skriptovacem, ktery nema ani poradne tooly a standardy vyvoje.

My v Jave mame i svoje vlastni objektove databaze, ktere ale moc nepouzivame, protoze jsou Java-specific. Pouzivame univerzalnejsi SQL databaze, ktere sice vyzaduji ORM vrstvu a dalsi opruzy, ale zato jsou standardni. Jiank bychom si v Jave taky mohli ukladat objekty a pracovat s nima bez nejakeho ORM.

94
Vývoj / Dalsi, UZ POSLEDNI KIKS V PYTHONU
« kdy: 01. 04. 2020, 02:10:44 »
Takze tohle uz je posledni vec, kterou me nastval Python. Prohlasuju, ze v Pythonu je VETSI BORDEL nez v Javascriptu. Dictionary v Pythonu nezachovava order klicu!!! A ne, nebudu se stvat s OrderedDict.

Takze kdyz si pri vyvoji microservices prevedu JSON na Dict, tak potom zpetne prevod Dict na JSON mi negarantuje order => bordel.

Takze tohleto je konecna. Prace s JSONem je v Pythonu totalni vopruz. Ja jsem chtel Python na rychlou vyrobu microservices, ale v porovnani s Node.js se Python proste nechyta.

Python je proste rokama zabordeleny jazyk. A nema zadne batteries included. To co je ve standarni knihovne je +- podobna slabota, jako to co ma Java v SDK. Stejne se vsechno musi dotahovat z vnejsich zdroju. A nekompatibilita mezi verzema Pythonu navic stejne nuti pouzivart virtual environment.

Bohuzel. Python je dobry tak leda pro nejake ty "data science" bastlire. Jinak je i skoda Python nekde zavadet - zbytecna otrava. Bash skripty to efektivne nahradit nedokaze, a na Node.js se to nechyta.

95
Vývoj / Re:Dalsi kiks v Pythonu!!!
« kdy: 01. 04. 2020, 02:05:37 »
Dalsi tvuji kiks, i male dite vi, ze nema pouzivat import *. Co se tyce osklivosti, cely koncept ORM je hloupy a osklivy. ORM je imho jen dusledek pristupu "neumim databaze a nechce se mi to ucit ani zaplatit odbornika". Takze s trochou nadsazky, je to reseni od patlalu pro patlaly. A vzhledem k urovni OOP v jave, to co je prasarna v tomto jazyku, nemusi byt prasarna v jinem. Bez ohledu na tuto knihovnu, se kterou jsem nikdy nedelal a ani nebudu a neposuzuji ji. Jestli hodlas python pouzivat jako javu, nikdy nebudes spokojeny, python neni java, v pythonu musis myslet jinak, odvolavam se na principy DRY a KISS.
[/quote]

Nonsense.
1. I male dite vi, ze frajer pouzije ORM pokud muze, protoze mu to snizuje bordel v kodu.
2. Co je DRY a KISS na tom, ze si potom nemuzu z instance te modelove tridy vygenerovat Dictionary? Java to ma mnohem vice DRY a KISS nez tady ten Python.

96
Vývoj / Dalsi kiks v Pythonu!!!
« kdy: 01. 04. 2020, 00:58:30 »
Dalsi kiks v Pythonu, a uz me ta platforma fakt zacina stvat.

SQLAlchemy.
Zaprve, pekne voskliva a komplikovana knihovna.
Zadruhe, i malinke dite vi, ze proste nemuzu v ramci takove knihovny naimplementovat jakousi agregaci modelovych trid pres inheritanci!!! Tohle by v Jave byla naprosta prasarna a juniorska skolacka chyba! Jenze ouha, Python nema Interfacy a v dobe vzniku SQLAlchemy nemel beztak jeste ani Dekoratory, co??? Fuj!

Kód: [Vybrat]
from sqlalchemy import *
from sqlalchemy.ext.declarative import declarative_base

engine = create_engine('sqlite:///sales.db', echo= True)
Base = declarative_base()


class Stock(Base):
    __tablename__='stock'
    id = Column(Integer, primary_key=True)
    ticker = Column(String)
    date = Column(DateTime)
    price = Column(Integer)


Base.metadata.create_all(engine)

97
Vývoj / Re:NoSql document databaze
« kdy: 29. 03. 2020, 11:39:08 »
1. Proc by mi nemel nejaka replika relacni databaze bezet? To prece neni vubec nromalni stav. Vam uz se nekdy na produkci snad stalo, ze vam z niceho nic nebezela replika Oraclu? A to jste na to nadaval, ze to tak je? Databaze ma byt schopna bezet NONSTOP. Takze tuhle vyhodu NoSql neberu, nevim co to je za usecase.
Protože spadla, indiáni vytrhali kabely, nebo nějaký jiný neplánovaný průser. Úplně normální stav, jen se děje zřídka.

A ve chvíli, kdy celý systém celý běží i ve chvíli kdy pár strojů ne, mám jako bonus i možnost ty stroje udržovat, aktualizovat a podobně bez jakéhokoliv viditelného výpadku. Tohle se u vás v korporátu nepovažuje za normální?

1. Tak presmerujete trafic na jinou repliku na jinem stroji
2. Nebo rozjedete svoji relacni databazi v Cloudu a nemusite se uz o udrzovani stroju starat vubec
3. A pokud pouzijete NoSQL abyste mel vyhodu kterou popisujete, tak musite prejit KOMPLETNE NA NOSQL, protoze system vam porad nebude fungovat, kdyz nejste schopni se o nej postarat kvuli relacnim databazim, ikdyz jich mate jen trochu. Proste bud tak, a nebo tak, a nic mezitim.

Takze jeste jednou:

Naco NoSQL???

98
Vývoj / Re:NoSql document databaze
« kdy: 29. 03. 2020, 03:01:26 »
volba technologie je vec vhodnosti, pouzijte technologii co se vam hodi.
klidne si drzte data v RAMce.

blablabla.

99
Vývoj / Re:NoSql document databaze
« kdy: 29. 03. 2020, 00:32:30 »
1. PostgreSQL budete třeba těžko provozovat v režimu „repliky po celém světě, a dokud vidím n/2+1 repliky, v pohodě funguju“.


2. Nad PostgreSQL musíte ručně stavět indexy.

3. Partitioning a dotazování přes víc serverů také v PostgreSQL nejdou dělat úplně snadno.

4. Pokud potřebuju v databázi ukládat dokumenty, proč bych se mořil s nějakým SQL nebo dokonce ORM?

1. Proc by mi nemel nejaka replika relacni databaze bezet? To prece neni vubec nromalni stav. Vam uz se nekdy na produkci snad stalo, ze vam z niceho nic nebezela replika Oraclu? A to jste na to nadaval, ze to tak je? Databaze ma byt schopna bezet NONSTOP. Takze tuhle vyhodu NoSql neberu, nevim co to je za usecase.

2. Nemusite si delat klidne zadne indexy :-) Date je tam jen kdyz budetep potrebovat. Ale ok, tohle beru, je to vice prace.

3. Podobne jako bod c. 1 - naco?

4. Protoze uz mate projekt kde mate nakonfigurovane ORM? Na to bych vam rekl proc bych se najednou jeste k tomu moril s NoSQL jenom proto ze potrebuju ukladat json a vyrabel k tomu dalsi konfiguraci.

100
Vývoj / NoSql document databaze
« kdy: 28. 03. 2020, 23:34:04 »
Mam dotaz na vsechny mistni no-typed-language a no-sql fandy. Muze mi nekdo z vas vysvetlit, proc, kdyz mam potrebu ukladat ve sve aplikaci rovnez i data typu "document", bych mel pouzit NoSql databazi namisto klsicke Postgres, kde si document-like data muzu strcit do sloupce s formatem JSON? Jdou nad tim normalne delat queries, muzu si jednotlive libovolne vnorene atributy toho JSONu dokonce i indexovat, pak si ten column muzu i v ORM namapovat na prislusnou tridy. Tak proc bych na to pouzil NoSQL databazi, kdyz muzu pouzit klasicke kombo ORM+SQL, a muzu pak ve sve databazi pouzivat jak relacni data, tak i document data, podle potreby.

101
Vývoj / Re:Zkušenosti s TypeScriptem
« kdy: 28. 03. 2020, 12:55:50 »
Zajímalo by mě, kde se reálně využije dynamičnost kódu? Z integer je kdesi v kódu najednou string a na základě toho se program větví jinak nebo co? Mě neskutečně irituje, že jsem některé projekty v php nepředělal na striktní typy, protože se pak všude musí dělat harakiry, aby se mi int porovnával opravdu jako int. Na chybu se pak přijde třeba za rok nebo vůbec.

U malych projektu typy nepotrebujes. U vetsich projektu tez ne:

Step 1. To rychle nadevelopis
Step 2. Pak das rychle vypoved, jako vymluvu uvedes ze jsou moc pozadu technologicky
Step 3. A v nove praci si das bacha abys taky jen developil.
Step 4. Na Root.cz nasledne prohlasujes ze skriptovaci jazyky jsou the best.
Step 4. Repeat.

102
Vývoj / Re:Zkušenosti s TypeScriptem
« kdy: 28. 03. 2020, 08:44:17 »
S tou transpilaci kodu v javascriptu, tak to mi vysvetlete. Dyt Javascript je snad v soucasnosti ten nejopatchovanejsi jazyk na svete, kdyz v tom dneska chcete delat, tak potrebujete prinejmensim babel, a to nemluvim o ruznych drobnych jazykovych rozsirenich ecmascriptu, ktere si case to case muzete dodat. A potom to jeste protahnete kolikrat pres webpack. Tak co komu prijde divneho na tom, ze to transpiluje z Typescriptu,  ne z toho babelu?  :D :D :D

A v linteru mivaji nekteri zapnute abecedni setrizovani atributu a funkci ve tride. A pak je tam jeste dalsi featura, nodemon. A ustavicne se neco meni. A pak nam Javistum neco rikaji, ze programujeme moc slozite  :D

103
Vývoj / Re:Aspektovo orientovane programovanie
« kdy: 28. 03. 2020, 07:01:59 »
Jinak používat custom AOP na projektu jakožto nějký magic pro logiku která má být normálně ve třídách, to jsem ještě neviděl, a dost mi to něčím smrdí. V podstatě AOP programátor používá pouze v roli uživatele už hotových, vyrobených knihoven.

Jo a ono to AOP mi nějak připomíná v Pythonu ty Dekorátory. Resp. šlo by to přes ně provozovat taky.

104
Vývoj / Re:Aspektovo orientovane programovanie
« kdy: 28. 03. 2020, 03:32:31 »
AOP je samozrejme zaklad nejvetsi chlouby Springu  a Javy a sice JPA anotace s JDBC, Transactional od Springu, a pripadne i Hibernate, diky kterym nemusime vubec resit rucne transakce, commity a dalsi spoustu boilerplatu ve velkem projektu - o tom si pythonisti muzou nechat jen zdat. Teda alespon do te doby, nez nejake pitome ucho co JPA ani nezna pouzije jen tak ze srandy a modrnosti nejakou NoSQL databazi nebo podobnou jinou sra cku.

Spring pouziva AOP i pro to aby sam o sobe mohlo fungovat jeho pojetí Inversion of Control.

Ale sam o sobe jsem nemel potrebu AOP tvorit a ani bych to nikdy nedelal, vyjma teda logovani. A to spise jako takova docasna obezlicka a to jeste k tomu na zdupanem osklivem projektu. Na mereni performance mozna tak u nejakych strarych projektu, jinak uz se pouziva Spring XRays, coz je samozrejme taky zalozene na AOP.

105
Vývoj / Re:Doporučte programovací jazyk pro Windows
« kdy: 24. 03. 2020, 19:37:58 »
Tvl to jsou programatori tohletoto... Nejprve jim nevoni Java, a pak ani nepochopi supereasy priklad.
Je videt, ze nejsi programator. Todle je nadherna ukazka toho, jak se programovat nema, nikdy :-).

To je javascript synku, jeste se mas hodne co ucit  ;)

Stran: 1 ... 5 6 [7] 8 9 ... 31