Hlavní navigace

Názory k článku 602SQL Server: historie velkého produktu vyvinutého v malém týmu

Článek je starý, nové názory již nelze přidávat.

  • 18. 5. 2018 7:29

    m&m (neregistrovaný) 46.189.28.---

    druhá polovina 90. let znamená přechod k generickým programovacím jazykům (Visual Basic, Delphi, .NET)"
    VB, Delphi ok, ale co ten .NET?!

    Ten spatřil světlo světa až 2002

  • 18. 5. 2018 8:41

    sql (neregistrovaný) ---.178-41-42.t-com.sk

    daju sa tie zdrojaky este odniekadial stiahnut? zo sourceforge to uz nie je mozne, zrejme ich odtial odstranili:(

  • 18. 5. 2018 11:14

    sql` (neregistrovaný) ---.178-41-42.t-com.sk

    jo, uz to ide, dakujem. v tom case, mi to ale vracalo len prazdne html s chybovou hlaskou, ktoru si uz zial nepamatam, ale bolo to nieco o neexistujucej URL/resource...

  • 18. 5. 2018 8:53

    mhi (neregistrovaný) 185.51.250.---

    Ja hlavne nechapu, jak z firmy, ktera delala neco uzitecneho (Text602, M602, atd.) vzniklo cosi, co se mi hnusi od pocatku do konce (zejmena kvuli ZFO a datovkam). Nevidim tam zadny produkt ani smysluplne reference, kde by se resil nejaky real world problem. Vsechno to je jen o umelych problemech vyvolanych statem nebo zakazky pro verejne instituce.

    Jedina reference kterou vidim a vymyka se tomu je UPC.

  • 18. 5. 2018 9:27

    Pavel Stěhule

    Musíte se nějak uživit - Microsoft dosáhl monopolu - a jejich původní trh byl nasycen případně vůbec neexistuje. Osobně si myslím, že digitalizace formulářů je určitě správně, a digitalizace státní správy, případně komunikace státu a občana je dobře. Jiná věc je, že jejich podpora Linuxu je +/- 0. Nicméně dělat pro státní instituce není žádný med - a návrh datovky, co vím, tak nebyl v kompetenci Software602.

  • 18. 5. 2018 14:07

    djmanas

    Správně to je, ale podával jste si nějaký formulář vytvořený soudruhy ze Software 602? Uživatelsky nepřítulný, zmatečný... Mno osobně tohle dodat mě, tak jim nezaplatím ani korunu...

  • 22. 5. 2018 4:52

    Lael Ophir

    Podotýkám že s Microsoftem to nemělo až tolik společného. V Software602 měli tehdy následující produkty:
    - M602 a T602. Spousta uživatelů, málo platících (ale přesto to bylo finančně zajímavé), a oběma produktům umřel trh, když zákazníci migrovali na Windows.
    - 602PC Suite (602Text a 602Tab). V komerční sféře neustál konkurenci produktů WordPerfect/Quattro Pro, AmiPro a MS Office. Ve státní správě se ale používal prakticky všude, nejspíš protože se tam už tehdy na rozdíl od komerční sféry dost hrálo na legální licence. Komerčně slušný úspěch. Zabilo to až uvolnění OpenOffice jako open source, protože SW dostupnému zdarma se těžko konkuruje. Software602 pak přišel s 602Office, což byl rebrandovaný OpenOffice s pár dodělávkami a importním filtrem pro dokumentové formáty 602PC Suite. Jenže kdo by si kupoval něco co si může stáhnout zdarma. Takže i 602Office umřel.
    - Mail602, mailový klient. Neustál konkurenci webmailů, Mozilla Thunderbird a MS Outlook Express.
    - 602SQL Server. Neustál konkurenci produktů MySQL, Oracle Express a MS SQL Server Express, protože SW dostupnému zdarma se těžko konkuruje.
    - 602LAN SUITE, tedy mail server kombinovaný s firewallem. Velké firmy použily Exchange nebo Lotus Notes, protože ty výrazně lépe plnily jejich potřeby. Malé firmy použily Sendmail, Postfix a spoustu dalších alternativ, nebo prostě nějaký webmail. Zpočátku se produkt prý prodával dobře, ale jak přišly zdarma dostupné alternativy, tak to umřelo. SW dostupnému zdarma se těžko konkuruje.

    Takže produkty té společnosti do značné míry zabil open source. Prostě se na trhu vyskytly alternativy dostupné zdarma, kterým nešlo rozumně konkurovat. To položilo i pobočku v USA. Logicky tedy hledali business, který jim open source tak snadno nepřeválcuje. A našli. Digitální podpisy, spisové služby, digitální archivy, vazba na datové schránky... Požadavky jsou dané (často poněkud úchylnou) českou legislativou, a autoři globálního SW se na tak malý trh nijak nehrnou. Navíc měla firma spoustu kontaktů ve státní správě, které dokázala velmi dobře využít. Možná nedělají žádné z hlediska admina "užitečné aplikace", ale je to dobrý business.

    Pánové mají můj respekt, že dokázali projít tím vším od T602 až po digitální archiv pro státní správu, a jejich firma to úspěšně přežila.

  • 22. 5. 2018 6:16

    Pavel Stěhule

    Lze dohledat rozhovory s R. Kauckým - https://www.penize.cz/podnikani/284276-richard-kaucky-za-komunismu-jsme-se-naucili-improvizovat-to-se-vzdycky-hodi - podle vlastních slov je z trhu vytlačily produkty, které byly zadarmo - nikoliv Open Source - oni na tento způsob distribuce přišli příliš pozdě, ale asi by to nic nezměnilo. A pak také - marketing Microsoftu, a také sw od MS. MS Office je kvalitní produkt - a verze 97 už byly stabilní, narvané funkcemi a i když nebyly zadarmo, tak pro domácí použítí byly laciné a pro firmy to nebyla extra láce. Microsoft měl zdroje na vývoj i na marketing. Tomu česká fy nemohla konkurovat - její prosperita byla daná specifickou situací 90 let tady - tady je tak malý trh, že krabicový vývoj neuživí - a na tom Sw na desktopu skončila.

    Všimněte si, že Microsoft nepřeválcoval jen Sw602, ale všechny ostatní pokusy o kancelářský sw. Dnes vedle MS může existovat jedině Open Source, díky jiné ekonomice. Monopol je monopol.

  • 18. 5. 2018 10:01

    Vinicius (neregistrovaný) 185.24.236.---

    Oběh, archivace a podepisování elektronických dokumentů je podle mého názoru real world problem a to nejen pro státní správu. Jen to nejsou produkty pro koncového domácího uživatele či malou kancelář.

    Na takovém trhu by firma nevydělala. V minulosti jsem si také kladl otázku proč 602 Pro PC Suite, když je tu buď Microsoft Office, nebo tehdy ještě OpenOffice.

  • 18. 5. 2018 10:47

    mhi (neregistrovaný) 185.51.250.---

    Ano, ale oni to pokud se nepletu (alespon dle verejnych referenci) dodavaji v podstate jen te statni sprave nebo organizacim napojenym na statni cecek. Kdyby to bylo reseni real world problemu, tak maji treba 3/4 referenci z realne komerce. Toto nejak nevidim.

    My (jako mikropodnik) mame taky system na archivaci dokumentu, kdyz jsem zacal zjistovat "jak to delat", na reseni od 602 ale i dalsich jsem se dival. Skoncili jsme s tim, ze jsem napatlal neco v PHPcku. Neni to uplne user friendly, ale ucel to splnuje 90% (tech 10% jsou problemy zpusobene zejmena legislativou).

  • 18. 5. 2018 11:37

    PQK

    Nebojte minimálně jedné "real world problem" reference se brzo dočkáte.

    Musím říct, že je jich DMS je ve firmě střední velikosti velice pěkně "použitečné".

  • 18. 5. 2018 9:02

    pvo (neregistrovaný) 2001:470:5c09:----:----:----:----:----

    Máte v článku chybu ve jméně autora Januš se jmenuje Drózd a ne Drozd :-).

  • 18. 5. 2018 11:16

    backup (neregistrovaný) ---.dip0.t-ipconnect.de

    prosel jsem si ty zdrojaky:

    1)klasika 90. let. Zpocatku jen C zdrojaky , casem pak nejake ty tridy. Ze by to bylo napsano v C++ podle mne nesouhlasi. To ted neni kritika, delam to zrovna tak.

    2) startkey=(tptr)co­realloc(keysi­ze, 85);
    Nejdrive jsem si myslel, ze je to chyba, protoze kdyz uz konkretni cislo, tak 42. Ale pak mi doslo ze 85 = 2 x 42 + 1

    3) Jak jsem to preletl, tak je tam opravdu vsechno, co skutecna databaze ma mit. Transakce, paging, analyza deadlocku pres cykly atd, atd . Ten pan musi byt fakt dobrej, hlavne proto, ze to musel delat sam. Nedovedu si predstavit, ze ta provazanost cele te problematiky je soucasne ve vice hlavach.

    4) Na tom kodu je podle mne take videt, proc je neco takoveho neopravitelne. Chybi mi tam vetsi struktura, rozdeleni na samostatne podskupiny - napr. jsem hledal, jak je udelanej ten sql-parser ... zadny lex nebo yacc soubor. Vsechno je to schovano v kodu. Cloves se sice sklani pred panem programatorem , ale soft inzenyrstvi je podle mne jinak.

  • 18. 5. 2018 11:36

    Pavel Stěhule

    V ručně psaném parseru bych až takový problém neviděl - určitě 602SQL určitě nebude jediná taková databáze. Ten kód se podle mne nemůže posuzovat dnešními měřítky - vznikal primárně v 90 letech v malém uzavřeném týmu, který navíc musel ukazovat výsledky a uživit se. I to C, a C++ byly tehdy mladé jazyky.

  • 18. 5. 2018 14:12

    Trident (neregistrovaný) ---.skvelynet.cz

    Mlady jazyk to tak to C++ - 7 let od prvni implementace. A to by dnesni gelousi jeste nad "mladosti" protestovali

    Ale C? Vzdyt ta potvora uz mela 20 let!!!

  • 18. 5. 2018 15:45

    xxxxx (neregistrovaný) ---.142.broadband5.iol.cz

    Předpokládám, že to čisté C, coby mladý jazyk, byl úlet.

    Ale s tím C++ pozor. To se na x86 dos/win (o win se v souvislosti s WinBase602 bavíme) opravdu prosazovalo velmi, velmi, pomalu. První náznaky se objevily teprve počátkem 90 let a to byl akorát tak class místo struct a možná, možná, overloaded operátory.

    Další zlom byl někdy kolem 93-94, kdy už to bylo mírně lepší, sem tam i počátky template, ale stejně dost špatné. Až někdy kolem 96-97 se to rozjelo a sjednotilo, že byl kód u těch C++ novinek +- kompatibilní.

    Pokud se pamatuji, některé první pokusné implementace classu (asi dělané interně jako precompiler) např. mívaly seznam virtuálních funkcí jako plný seznam (všech) pointerů za daty struct. Až později si to compilery začaly zvládat hlídat dle typu classu a dávaly jen jediný pointer na tabulku společnou pro daný typ. Nebo třeba Borland si pro win udělal své vlastní rozšíření pro zpracování messages (pokud si vzpomínám, za názvem virtuální funkce v classu se udělalo =[XXX] kde xxx bylo int číslo zprávy které si dal navíc k tabulce vitruálních funkcí, pěkné, pohodlné, ale nekompatibilní a mělo potíže s typovou kontrolou) a až později /95+/ to nahradil klasickými RESPONSE_TABLE pomocí define a templates.

  • 18. 5. 2018 16:03

    Pavel Stěhule

    To s tím C byla spíš ironie - když si vzpomenu na rok 91, kdy jsem byl v prváku na výšce, tak v Céčku programovali pár největších borců a pro mne a pro lidi z okolí, kde jsem byl, bylo Cčko poměrně exotický jazyk. Starší kódy byly ve Fortranu, novější pak v Turbo Pascalu. Pak se to začalo měnit, až s nástupem Linuxu, což bylo spíš až po roce 96-97.

    Co jsem chtěl říct. Tipoval bych, že lidí, kteří začátkem 90 let to měli zkušenosti s Cčkem na tolik, aby řešili kvalitu kódu tu asi moc nebylo.

  • 18. 5. 2018 16:25

    xxxxx (neregistrovaný) ---.142.broadband5.iol.cz

    Pravda, ohledně řešení kvalit kódu, námitku beru. To je fakt.

    Obzvláště v souvislosti s ANSI C (a třeba i lepší typová kontrola, ...). To teprve začínalo a v počátcích 90 bylo vidět i kódy v původním zápisu K&R. Člověk byl rád, že se přeložilo (často zápis mix původní K&R, něco mezi tím i ANSI C dohromady) a fungovalo (ideálně pod více překladači, pro jistotu). Natož aby se zabýval kvalitou kódu.

  • 18. 5. 2018 17:33

    Pavel Stěhule

    Nemůžu generalizovat, jen vzpomínám na 90 léta - a i když jsem ze školy věděl o sw inženýrství, tak praxe byla o tom, to hlavně nějak udělat - hromada komponent byla tak zabugovaná, že jsme týdny hledali kód, kdy se knihovna nebo komponenta chovala aspoň trochu slušně. Člověk spálil tolik času chybama sw, že na kvalitní kód nezbyl čas (u běžného byznys kódu - u kritických aplikací to bylo něco jiného). Navíc většina lidí kolem byla samouci - v týmu, kde jsem začínal jsem já stavař s SI měl k IT nejblíže - a pak tam byla totální všehochuť. O sw metrikách, formálních procesech, automatických testech, .. se začalo mluvit spíš tak po roce 2005 - a pak už to bylo horké téma po roce 2010.

  • 19. 5. 2018 17:20

    MartinX (neregistrovaný) ---.chello.sk

    Suhlas. Na vyske v 1. rocniku (90/91) stale "letel" Pascal a dokonca aj pomocny program k cipu, ktory som navrhoval ako diplomovku som pisal v 1995 v Pascale. Az ked mi diplomovy veduci povedal, ze ak chcem byt "cool" tak to mam napisat v C tak som sa za tyzden naucil zaklady C, prepisal som to a multiplatformne skompiloval pod Windows aj pod Unixom.

  • 21. 5. 2018 9:54

    L. (neregistrovaný) 91.219.246.---

    Já tedy v roce 1995 používal C docela běžně. A Pascal jsem používal i později, protože Delphi.

  • 18. 5. 2018 19:38

    ded.kenedy (neregistrovaný) ---.v4.cust.lemointernet.cz

    Až někdy kolem 96-97 se to rozjelo a sjednotilo, že byl kód u těch C++ novinek +- kompatibilní.

    Tehdy ta doba byla porad jeste hodne jalova. Hlavne se prekladace lisily v tom, co ktery umi. Zive si vybavuju, ze Mozilla mela (nebo mozna porad ma, nevim) relativne nevelky seznam vlastnosti, ktere se mohly pouzivat, aby je zvladly prekladace na vsech cilovych platformach.

  • 18. 5. 2018 20:37

    xxxxx (neregistrovaný) ---.142.broadband5.iol.cz

    Napsal jsem to blbě, nejasně. Měl jsem na mysli, že v těch letech už se člověk mohl spolehnout na to, co se cca 15 let před tím zavedlo jako C++ novinka.

    Takže class byl class, fungovalo základní dědění (virtuální dědění byl problém) a virtuální funkce (libovolný počet) nafoukla data o pouhý jeden pointer (+ jednu společnou tabulku na class) a fungovaly. Základní overloaded operátory fungovaly /dostatečné pro iterátory/ (dokud ze nezačaly vnořovat či řetězit, to občas selhalo kdy který použít). To vše běhalo prakticky všude (co si pamatuji).

    Ne, že se začaly fungovat C++ novinky 90 let (jako template, ...).

    P.S.: Bavím se o dos/win x86. Neberu v úvahu ani GNU / Linux (potažmo gcc). Linux v tu dobu stále začínal. Někdy od 93-94 se už dal používat i na mírně vážnější věci (Slackware to jistil, díky díky za něj), ale stále to bylo v plenkách.

  • 18. 5. 2018 20:52

    xxxxx (neregistrovaný) ---.142.broadband5.iol.cz

    Zase blbě nepřesně. Iterátorem myslím akorát tak primitivní upravený offset do pole [] a případně ++ resp. += pro odpovídající index. Ne template iterátory, jak si je člověk představí dnes.

  • 18. 5. 2018 13:39

    Kiwi (neregistrovaný) 46.13.196.---

    Neviděl jsem sice ten kód, tak nemohu posuzovat. Nicméně - mám pocit, že se u nás postupně sklouzlo k jakémusi flákání a flikování ve stylu "to neřešte, na to je knihovna, to nepište ručně, na to je generátor". Myslím, že to i souvisí s převládajícími názory tady na rootu v diskusích, pokud jde o potřebné vzdělání a schopnosti v IT. Jenže to je v podstatě stejný přístup, k jakému jsme se dostali třeba ve strojírenství - prostě montovny. Hlavně rychle, rychle, kvalitu neřešme, do inovací se nepouštějme... To nemusí být z dlouhodobého hlediska rozumné. Často je opravdu lepší místo použití nějaké univerzální knihovny napsat vlastní podmnožinu toho, co potřebuji, přesně sobě na míru. Ta univerzální řešení nebývají optimální, právě protože jde nutně o kompromisy, už ze své podstaty. Soft inženýrství je právě umění posoudit to a správně se rozhodnout.

    A k věci - pokud jde o parser, tak oba přístupy mají svá pro a proti. Generovaným parserem se dá ušetřit na počátku nějaký čas - hlavně u lidí, kteří napsat parser prostě neumějí. Ručně psané parsery bývají založeny na LL(1), zatímco generované na LR(1). Ručně psaný parser bývá kompaktní, řešený rekurzivně, z hlediska kódu velmi přehledný a umožňující v každém kroku různé "vedlejší" reakce - u kompilátorů shromažďovat informace pro optimalizace generovaného kódu, z uživatelského hlediska ale nejčastěji k vyhození co nejvýstižnějšího chybového hlášení. V tomhle generované parsery prostě kulhají.

    Nechci vyvolávat nějaký flame, ale čistě z mého praktického pohledu - 1) pokud je možné sestavit gramatiku v LL(1) formě, pak bych jí dal přednost před LR(1) - ač restriktivnější, připadá mi taková čistší; 2) pokud mám LL(1) gramatiku, tak bych raději napsal rekurzivní parser "ručně". LR, resp. LALR generátory považuji stále za určitou znouzectnost, instantní polívku oproti poctivému vývaru.

  • 18. 5. 2018 19:00

    belzebub (neregistrovaný) 82.142.76.---

    Pokud pracujete jako ucitel na IT univerzite, a mluvite o vyuce, tak mate castecne pravdu. Pokud mluvite o praci jako programator, jste totalne mimo a Vase tvrzeni jsou naproste blaboly viz.:

    "Hlavně rychle, rychle, kvalitu neřešme, do inovací se nepouštějme... " - pokud Vas za to nekdo plati, tak neoceni ze jste si napsal vlastni (nekompletni, zabudovany a pomaly) xml parser, ale oceni pokud reseni funguje a je dodane vcas.
    Nechapu jak si muzete myslet, ze napsat neco existujiciho znovu je inovace..

    "Ta univerzální řešení nebývají optimální, právě protože jde nutně o kompromisy, už ze své podstaty." - kazde inzenyrske reseni je kompromis. Navic to, ze nejake obecne reseni o kterem mluvite neni optimalni, neni tvrzeni ktere by se dalo jakkoliv hodnotit (protoze se netyka niceho konkretniho). Ja osobne ale preferuji kompromis typu "parsovani xml zpravy trva o 2.3ns pomaleji s expatem nez s rucne psanym xml serverem, coz mi nevadi, protoze poslani zpravy na server pres sit trva radove milisekundy", nez kompromis (ktery obhajujete): "sice jsem to psal pul roku, a porad to obcas pada, ale kod je napsany uplne nacisto a nepouziva zadnou cizi knihovnu"

    "Často je opravdu lepší místo použití nějaké univerzální knihovny napsat vlastní podmnožinu toho, co potřebuji, přesně sobě na míru." - zde si pletete slovo "Casto" se spojenim "v ojedinelych, velmi specifickych pripadech".

    "..u kompilátorů shromažďovat informace pro optimalizace generovaného kódu, z uživatelského hlediska ale nejčastěji k vyhození co nejvýstižnějšího chybového hlášení. V tomhle generované parsery prostě kulhají." - pouzival jste vubec nekdy aspon treba ten lexx/yacc? Prijde mi ze asi ne, protoze jinak byste tohle tvrdit nemohl.

    Vas poctivy vytvor si muzete strcit za klobouk, znovuvynalezani kola je mozna zabavny konicek, ale strasna zhouba profesionalnich programatoru

  • 19. 5. 2018 1:26

    unicode (neregistrovaný) ---.ipv4.broadband.iol.cz

    Podle mě napsat něco existujícího znovu a _líp_ inovace je.

  • 19. 5. 2018 22:56

    belzebub (neregistrovaný) 109.75.159.---

    Teoreticky mate pravdu, v praxi ale existuje u kazdeho problemu urcita hranice, za kterou uz je bud nemozne neco zlepsit, nebo jakekoliv dalsi zlepseni je naprosto zanedbatelne. Coz pak znamena, ze kazde dalsi zlepseni nestoji za tu praci. Navic naprosta vetsina lidi nedokaze lepsi reseni vymyslet nebo napsat, pripadne jim lepsi reseni zabere neumerne mnoho casu.
    Debata navic zacala diskusi na tema pouzivani knihoven, coz znamena, ze se bavime v naproste vetsine o implementaci algoritmu starych treba i desitky let. V teto oblasti je naprosto minimalni prostor pro nejakou smysluplnou inovaci.
    Takze napr. dalsi kompresni algoritmus, ktery je o 0.01% lepsi nez stavajici nejlepsi dnesni kompresni algoritmus je bezesporu principialne "inovace", nicmene je to inovace dost nezajimava a jeji pouziti prinese spise problemy (poslete nekomu neco zkomprimovane Vasim algoritmem, ale on nebude mit dekoder) nez uzitek .
    Takze napsat/udelat neco existujiciho znovu a lepe sice teoreticky muze byt inovace, v drtive vetsine pripadu ale neni.

    Fascinuje me, ze mezi programatory neustale potkavam zastance teto zcestne filozofie "vsechno si vzdy udelam sam, protoze vsechno udelam lepe nez ti prede mnou", zajimco v jinych oborech takhle snad nikdo neuvazuje.. nebo jsem tedy zatim nepotkal automechanika ktery by si na soustruhu vyrabel vlastni srouby pro uchyceni kol a prohlasoval ze jeho srouby, ktery jeden vyrabel pul hodinu (a vyjde tak na min.150kc) sou hrozna inovace, protoze sou o 0.01g lehci nez to co se da koupit za par korun hotove, nebo zednika, ktery by odmital pouzivat koupene cihly a palil by si vlastni a kazdemu kdo stavi z koupenych by rikal ze je liny diletant, protoze jeho cihly jsou mnohem presnejsi a rovnejsi (i kdyz stoji 10x vice a nikdo ten rozdil v rovnosti bez laseroveho mereni nepozna).

  • 19. 5. 2018 23:48

    Pavel Stěhule

    Tady asi každý má své trochu jiné zkušenosti - v závislosti na tom v co kdo dělal, v čem dělal, a s čím se spálil. U jednoduchých knihoven asi není co řešit, ale u větších knihoven, u kterých víte, že používáte tak 10% už může být efektivnější napsat si vlastní kód. Případně máte na výběr z desítek knihoven, ale než najdete tu, která pro Váš use case funguje, tak opět může být jednodušší napsat si vlastní knihovnu.

    Analogie se strojařinou nebo stavařinou v IT jsou dost mimo - ten obor je výrazně mladší - unifikace, standardizace je na mnohem nižší úrovni - kvalita je mnohem horší - většinou máte mnohem víc stupňů volnosti. V některých prostředích integrace nějaké další knihovny vůbec nemusí být jednoduchá záležitost. Musíte se naučit číst dokumentaci, pochopit filozofii, sžít se s bugama. V některých prostředích některé knihovny nemusíte mít, nebo nemusíte mít k dispozici aktuální verze, nebo některé verze jsou v některých prostředích nestabilní.

    Po zkušenostech třeba s knihovnou libXML2 si dovedu představit, že je jednodušší si napsat vlastní jednoduchý parser. Něco jiného je, když do toho začnu řešit XPath, xslt, ... tam už se vám vyplatí investovat do akceptace třeba složitější knihovny.

  • 20. 5. 2018 0:06

    Pavel Stěhule

    Taky ještě záleží na použité technologii. Když programuje ve vysoko úrovňovém jazyku, tak se snažíte využít komponenty, knihovny napsané v nízko úrovňovém jazyku - což v těchto jazycích jde většinou docela jednoduše. Určitě bych neměl tendenci si psát vlastní parser XML v PHP nebo vlastní algoritmus pro sort.

    Jakmile používáte nízko úrovňový jazyk, tak tam jste trochu jinde - použít cizí knihovnu může být výrazně pracnější, dražší, a naopak napsat si vlastní implementaci jednoduchého algoritmu může být výrazně jednodušší.

  • 21. 5. 2018 15:49

    Karel (neregistrovaný) ---.cust.nbox.cz

    Zrovna dnes jsem měl doma instalatéra. Sice netrval na tom, že si bude sám vyrábět vodovoní baterii, ale měl poměrně divně vypadající nástroj. Povoloval a utahoval tím nějaké šrouby. Byly to tři trubky spojené na dvou místech kloubem. Prý mu to vyrobil kamarád a on tím dokáže pohodlně odšroubovat/přiš­roubovat baterii bez ohledu na to, kolik je kolem ní místa. Laicky mi to přišlo jako kardan, kde na jednom krátkém konci je násuvný bit a na druhém rokojeť.

    https://cs.wikipedia.org/wiki/Kardan%C5%AFv_z%C3%A1v%C4%9Bs

    A o tom to podle mne je. Ne o tom psát si vlastní kompresní algoritmus, ale o tom sám pro sebe si napsat lepší nástroje. Já těhle jednoúčelovek mám docela dost. Výhoda je, že přesně vím, co to dělá a co ne. Vlastní XML parser jsem nepsal, ale mám třebas vlastní parser na soubor "hosts", který mi ho umí i přepisovat. Jasně, mohl bych implementovat něco jako No-IP, ale zrovna tady mi to přišlo snadnější si to udělat po svém, bez internetu a bez třetí strany.

  • 19. 5. 2018 8:09

    Tomas Z (neregistrovaný) ---.rychlydrat.cz

    No zrovna XML je takova obluda, ze jsem uz videl par aplikaci kde pouzili pro parsovani ocekavaneho primitivniho xml univerzalni knihovnu (nevim jestli expat nebo neco jineho), fungovalo to, bylo to dost rychle, ale nikomu nevadilo ze nechanym (defaultnim?) nastavenim vhodne xml dokazalo pri parsovani posilat ven obsahy souboru. Tim chci rict, ze spravne pouziti knihoven ma rezii se ctenim dokumentace, nekdy licence, release notes novych verzi (o nechani zavislosti na verzi stare nemluve), ktera tu rovnovahu v dlouhodobem behu muze dost posunout - coz mozna nevadi programatorum co maji deadline, ale udrzbe. (a ano, na kolene psane veci maji taky bezpecnostni problemy)

    K puvodnimu tematu - co si vagne pamatuju, diskuse nad generatorem parseru probehla, ale v dobe kdy ten rucne psany parser byl davno hotovy a fungoval, a generovany by bylo (a) nutne napsat a odladit a (b) asi by byl pomalejsi - a tehdy se rychlost brala vazneji nez dnes.

    Jinak i Winbase pouzivala pokud pamatuju par externich knihiven (tusim crypto knihovnu a lemmatizator pro fulltext?), a tehdy to az tak jednoduche nebylo (rozchodit na Linuxu, blbosti jako ze crypto knihovna pouzivala xor jako jmeno promenne takze fungovala jako C ale ne C++, o tom ze nefungovaly out-of-box na Itaniu nemluve)

  • 19. 5. 2018 9:52

    Filip Jirsák

    Ten příklad s XML je úplně mimo. Načítání externích zdrojů je přímo součástí standardu, takže byste to musel ošetřit i při psaní vlastního parseru. Tím, že byste napsal parser na míru konkrétní struktuře dokumentu byste stejně větší rychlost nezískal, naopak byste přišel, o všechny ty optimalizace, které jsou už v parserech udělané. Navíc XML parsery mají standardní rozhraní, takže nehrozí, že byste kvůli nové verzi XML parseru musel přepisovat aplikaci. Zkrátka ta režie je řádově menší, než kdybyste si psal vlastní parser. Navíc když zvažujete napsat si něco vlastního, je potřeba dát si velký pozor na to abyste porovnával porovnatelné. Jinak rozhodne „žádná knihovna neumí to, co by mohla umět naše knihovna, kdybychom měli neomezený čas a neomezené zdroje“ a končíte u toho „naše knihovna jakž takž zvládá aspoň tohle, což nám s odřenýma ušima stačí; ostatní knihovny toho umí mnohem víc, ale jednou, až budeme mít čas, taktu knihovnu doděláme, a to pak bude něco“.

    Akorát zrovna SQL je na parsování dost komplikovaný jazyk – zajímalo by mne, zda třeba Oracle SQL se všemi jeho rozšířeními vůbec jde popsat nějakým formálním zápisem.

  • 19. 5. 2018 11:46

    Pavel Stěhule

    Mám pocit, že Oracle i DB2 mají ručně psaný parser - jistý si samozřejmě nejsem - zdrojáky jsem neviděl :-). Postgres tak trochu balancuje na hraně možností bizonu - některé výrazy jsou generičtější a pak se musí dořešit v další etapě - někde jsou potřeba navíc závorky, aby se předešlo kolizím. V každém případě bizon neumožňuje dynamicky rozšiřovat gramatiku - což limituje extenze - nelze napsat napsat extenzi, které by rozšiřovala SQL syntax - což z 99% nevadí, ale občas by se hodilo.

  • 20. 5. 2018 8:25

    Ivan (neregistrovaný) 165.225.72.---

    Akorát zrovna SQL je na parsování dost komplikovaný jazyk – zajímalo by mne, zda třeba Oracle SQL se všemi jeho rozšířeními vůbec jde popsat nějakým formálním zápisem.

    Pokud jde o rozsireni, tak treba takovy MySQL je na tom mnohem hure, presto ze je mladsi. U Oracle jde predevsim o zpetnou kompatibilitu. Vsechna klicova slova je stale mozne pouzit jako udentifikatory. A s tim si zadny tool neporadi.
    Napr.

    select * from commit;
    select * from T join join on (T.C = join.C)
    select * from model model partition by C1 dimension by C2 ...

    PS: udrzovat vlastni parser napsany v imperativnim jazyce je hard-core. I mala zmena gramatiky muze znamenat ze musite prepsat uplne vsechno. Pouziti deklarativniho generatoru usetri spoustu prace, problem nastane az kdyz narizite na limitty toho toolu.

  • 20. 5. 2018 11:53

    Filip Jirsák

    Já si právě nemyslím, že by Oracle SQL mělo nějakou jednu gramatiku. Když se dívám na popis různých příkazů a konstrukcí, připadá mi, že je za tím ručně psaný parser, který se ad-hoc rozšiřuje o parsování nových konstrukcí, aniž by to bylo zastřešené nějakou jednotnou gramatikou. Pokud je nad tím vším jednotná gramatika, je podle mne dovedně skrytá.

  • 21. 5. 2018 9:19

    Ivan (neregistrovaný) ---.tmcz.cz

    Gramatika se da vytvorit. Bohuzel neni 100% kompatibilni s Oracle. Prave kvuli tomu, ze Oracle si nemuze dovolit rict, ze napr. slovo "MODEL" bude v dalsi verzi vyhrazene slovo a proto uz nadale nikdo nesmi vytvorit tabulku s timto jmenem. Tahle gramatika puvodne byla ISO SQL 92 a nakovec z toho vznikl parser Oracle PL/SQL:

    https://github.com/ibre5041/plsql-parser

  • 21. 5. 2018 16:19

    Karel (neregistrovaný) ---.cust.nbox.cz

    Oracle má vlastní parser už proto, že tam toho strašně moc záleží na metadatech. Jeden a ten samý text může znamenat něco jiného podle toho, co existuje za tabulky atd. Přidejte konstrukce, které fungují jen s "look ahead" o poměrně vysokém čísle. LL parser na to sice funguje poměrně slušně, ale občas mu prostě dech dojde.

    Oblíbený příklad jsou tyhle tři selecty. Oracle první a třetí zpracuje, druhý ne. Překvapení je v tom, že druhý ne. Protože Oracle dovolí použít "inner" jako alias tabulky (viz 1) a zároveň je "inner" v "inner join" nepovinné (viz 3), tak by podle gramatiky mělo být i 2 zcela validní. No a není. Podle toho, jak to má která gramatika ošetřené, se prostě některý z těch 3 dotazů povede a zbytek ne. Ale přesně tak jak to má Oracle - 1 a 3 ano, 2 ne, se ta gramatika napsat nedá, tam už se holt musí vnutit nějaký IF na "pokud dvakrát inner tak..."

    select * from dual inner inner join dual on inner.dummy = dual.dummy
    select * from dual inner join dual on inner.dummy = dual.dummy
    select * from dual inner2 join dual on inner2.dummy = dual.dummy

    No a přihoďte fakt, že lze založit tabulku jménem "inner" a sloupcem "dummy", díky čemuž začne fungovat všechno tohle:

    select * from inner join dual on inner.dummy = dual.dummy
    select * from inner inner join dual on inner.dummy = dual.dummy
    select * from inner inner inner join dual on inner.dummy = dual.dummy

    A ještě jedna drobná věc: udržovat ručně napsaný parser není zdaleka tak pracné, jak si někteří lidé myslí. Pořád je to parser rozlišující terminály a neterminály atd. a dokud se nepřekopají základy gramatiky, tak se prakticky nic nepřepisuje, jen se dopíšou nové věci. Úprava takového parseru zkrátka není řádově složitější než úprava gramatiky.

  • 21. 5. 2018 17:24

    Pavel Stěhule

    Několikrát jsem při migraci z Oracle do Postgresu narazil na fakt, že parser v Oracle ignoroval chybný zápis, kde byly některé symboly navíc - tak by se asi z gramatiky generovaný parser nechoval. Jinak souhlas, údržba ručně psaného parseru nemusí být nijak extra pracná - záleží jen na tom, jak je to napsáno.

  • 21. 5. 2018 20:38

    ehmmm (neregistrovaný) 185.193.85.---

    Tak tohle je bomba! Chtel bych mit cas na zkoumani podobnych blbosti. :)

    I kdyz ted si uvedomuji, ze ho vlastne mam dost, jenom zkoumam jine blbosti.

    Ten posledni sql dotaz s 3x inner mi pripomina vtip ze zakladni skoly, jestli znate vetu, kde je trikrat "ti" po sobe. "U riti ti tika budik."

    Naprosto bez ironie dekuji za komentar, zlepsilo mi to naladu.

  • 19. 5. 2018 17:24

    Kiwi (neregistrovaný) 46.13.196.---

    Pokud mluvite o praci jako programator, jste totalne mimo a Vase tvrzeni jsou naproste blaboly -- Pokud se živíte jako architekt či zedník, který vytváří panelové domy a paneláková sídliště, tak máte pravdu. Pokud byste tušil, co obnáší "poctivá" stavařina, jste totálně mimo a Vaše tvrzení jsou naprosté bláboly. Asi tak.

    pouzival jste vubec nekdy aspon treba ten lexx/yacc? Prijde mi ze asi ne, protoze jinak byste tohle tvrdit nemohl. -- Ano, konkrétně flex a bison. Jinak bych to netvrdil. A vy jste někdy psal parser, od kterého se chce, aby případnou chybu oznámil poněkud košatěji než prostě jen "line 150: syntax error", když někde o 50 řádků dříve chybí nějaký symbol?

    znovuvynalezani kola je mozna zabavny konicek, ale strasna zhouba profesionalnich programatoru -- Víte, co je zhouba profesionálních programátorů? Když na auto jebnou kola z lokomotivy, protože přece "nebudou znovuvynalézat kolo".

  • 19. 5. 2018 23:46

    belzebub (neregistrovaný) 109.75.159.---

    Nevim kam mirite s vasi architektonickou analogii, ale kdyz uz stavarina, nebo architektura, tak se bavime o TOP level navrhu. Zadny architekt ( pokud zrovna nebude navrhovat zakladnu na mesici nebo podmorsky tunel) nebude navrhovat jak vyrabet beton, nebude rozkreslovat kam prijde kazda jednotliva cihla a nebude specifikovat jak se maji vyrabet ramy oken. Naopak navrhne dum/most/cokoliv z existujicich komercne snadno dostupnych a pro dany ucel dostatecne vyhovujicich komponent - at uz jsou to betonove prefabrikaty, cihly, tvarnice, armatury, a beton ktery Vam privezou v michacce.

    Ja s Vami polemuzuji v tom, ze jste psal, ze pouzivani knihoven a frameworku je "lenost" a ze je "casto lepsi si to napsat sam", coz v te stavarske analogii odpovida tomu, ze byste pozadoval, aby si architekt sam vyrabel cihly a specialni nestandardni okna - a pozor, nerikam ze to v nekterych OJEDINELYCH pripadech neni spravny postup - rikam ze ve VETSINE beznych pripadu to NENI spravny postup.

    ad lexx/yacc - takze pokud ano, tak vite, ze to jaka se ohlasi chyba, co si "pamatujete" a co ne, je ciste na Vas, ne na generatoru. Pokud vsechno napisete jako jednoradkove callbacky kde jenom nedo nekam pridate, tak to je chyba Vas, jako programatora, ne (f)lexu a yaccu/bisonu (coz je navic uz temer prehistoricka technologie). Mira detailnosti chyboveho hlaseni je ve vasi rezii a muzete ji mit detailni jak chcete. Generator to sice neudela za Vas, ale ani Vam v tom nijak nebrani. Vas argument byl ve stylu ze to s automatickymi generatory parseru NEJDE, coz tvrdim ze neni pravda.

    ad zhouba kolo z lokomotivy na auto - to je vemi smesny a nesmyslny priklad. Kola na auto jsou vec, ktera je bud normalne k dostani od subdodavatelu a muzu je koupit hotove, nebo je pro novy model unikatni a pak se tedy nakreslit musi, nicmene kolo neni neco co by se dalo prirovnat k SW knihovne. To je spis neco jako sroub nebo lozisko. Nehlede tedy na to ze lokomotivy pouzivaji dvojkoli, tj. toto proste nejde, ale to beru ze neni relevantni.

    Abych opustil analogie - znovuvynalezani quicksortu pri psani eshopu je absolutni silenstvi. Pri psani prakticky vseho je znovuimplementace quicksortu absolutni silenstvi. Mozna pro sw vesmirne sondy neni, ale i tam bych byl opatrny. A misto quicksortu si doplnte regularni vyrazy, kompresni algoritmy, komunikacni protokoly apod.
    Nikdo nikdy neoceni, ze jste pri psani noveho eshopu firmy Omacka a syn implementoval vlastni quicksort, vlastni databazi nebo www server. Nikdo. Navic Vam to pak asi Omacka a syn nebudou chtit zaplatit, protoze s tim stravite mesice a budete za to muset chtit desitky tisic a Vas rucne napsany webserver s eshopem specialne pro Omacku nebude rychlejsi, prehlednejsi, ani neprinese Omackovi vic zakazniku nez to co nekdo upravi ze sablony za tyden a proda za 20 000.
    Nehlede na to, ze ten Vas rucne napsany eshop Omackovi nikdo jiny nez Vy nemuze upravit nebo rozsirit, zatimco ten sablonovity muze Omackovi upravit nebo rozsirit prakticky kazdy.
    Omackovi bude uplne jedno ze Vas server ma o 0.1ms rychlejsi odezvu a ze na disku bere o 5% mene mista. To nejsou veci ktere by ho zajimaly.

    Abych se vratil k Vasemu autu: loziska, srouby (mozna krome ojnicnich), matice, podlozky, tesneni, apod. - pokud cokoliv z toho nejaky inzenyr navrhne vyrabet, misto koupit hotove, tak bude za blbce.

    A na zaver - z vasi zminky o "poctive" stavarine a dalsich naznaku mam pocit, ze si myslite ze vetsina architektu navrhuje mrakodrapy v New Yorku, nekolikakilometrove mosty preklenujicimi morske zalivy apod. A ze vetsina programatoru programuje vesmirne sondy, operacni systemy a inteligentni roboty.

    Jenze vetsina architektu/stavaru navrhuje uplne bezne rodinne domky, Vami opovrhovane bytove domy, silnice, dalnice, mosty pres dalnice, supermarkety, vyrobni haly, programatori delaji firemni stranky, eshopy, skladove systemy, ucetnictvi, zabezpecovaci systemy a dalsi bezne, mozna nudne, ale potrebne veci. Pro Vas jsou tyto veci asi "nepoctive", ale nikdo z techto lidi nepotrebuje vyrabet vlastni cihly nebo si psat vlastni parsery xml.

  • 20. 5. 2018 13:01

    ded.kenedy (neregistrovaný) ---.v4.cust.lemointernet.cz

    Kola na auto jsou vec, ktera je bud normalne k dostani od subdodavatelu a muzu je koupit hotove, nebo je pro novy model unikatni

    Abych se vratil k Vasemu autu: loziska, srouby (mozna krome ojnicnich), matice, podlozky, tesneni, apod. - pokud cokoliv z toho nejaky inzenyr navrhne vyrabet, misto koupit hotove, tak bude za blbce.

    Ty analogie jsou vylozene padle na hlavu. Ve stavebnictvi a v prumyslu jsou jednotlive dily vetsinou standardizovane a snadno zamenitelne. Staci specifikovat vlasnosti a dil najdes, to ve vyvoji software neplati.

    Tam je to spis co vyrobek to unikat nebo atyp, ktery ma specificke pozadavky. Malokdy se stane, ze k tomu, co potrebujes, mas presne odpovidajici knihovnu nebo komponentu. Casto to dopada tak, ze do ctvercoveho prurezu potrebujes vlozit kruhovy dil, a musis vymyslet nejaky hack, jak to udelat. Uz mockrat se mi stalo, ze jsem v dobre vire pouzil nejakou knihovnu, abych s postupem casu zjistil, ze mi jeji logicka nevyhovuje nebo ze obsahuje koncepcni chyby. Vetsinou to pak skoncilo tim, ze jsem si celou funkcionalitu napsal od nuly a usetril tim spoustu casu, protoze nova knihovna zacala lip pasovat na me pozadavky.

  • 20. 5. 2018 13:30

    Filip Jirsák

    Ta doba, kdy bylo v IT vše atyp, je naštěstí už dávno pryč. Pro výměnu dat se používá standard XML (nebo aspoň JSON nebo nějaký jiný cool formát), komunikuje se opět nějakým standardizovaným protokolem (nejčastěji HTTP/HTTPS). Asi záleží na tom, v jaké oblasti IT se pohybujete. Ale existuje obrovské množství aplikací a IT systémů, a to množství je možné jen díky tomu, že už na spoustu věcí existuje hotový kód, a do výsledného produktu jen stačí ty hotové krabičky vhodně poskládat a navzájem je propojit. Úplně stejně, jako je to v tom stavebnictví nebo automobilovém průmyslu. Protože kdyby se to všechno mělo dělat od začátku, není prostě v lidských silách toho udělat tolik.

  • 20. 5. 2018 15:20

    ded.kenedy (neregistrovaný) ---.v4.cust.lemointernet.cz

    Pro výměnu dat se používá standard XML (nebo aspoň JSON nebo nějaký jiný cool formát), komunikuje se opět nějakým standardizovaným protokolem (nejčastěji HTTP/HTTPS)

    A jak toto prispiva do diskuze o znovupouzivani kodu a knihoven? Zaprve, myslel jsem, ze se tu nebavime na urovni integrace systemu, ale bezne tvorby programu, tj. implementace parseru, tridici algoritmu, apod.

    Zadruhe, XML nebo JSON a protokol HTTP jsou jen formaty a protokol pro vymenu dat a neresi problem, ze aplikace ma data ve formatu ctverecku a protokol vyzaduje format kolecka.

    Kdyz se tady bavime o parsovani SQL ve Winbase, tak by to podle dnesnich programatoru melo vypadalo tak, ze se vezme kod v SQL, posle se pres HTTPS nejake sluzbe vcetne gramatiky ve formatu JSON a ta ji vrati syntakticky strom opet v JSON, aby si to databaze mohla prevest do sve interni reprezentace.

    Úplně stejně, jako je to v tom stavebnictví nebo automobilovém průmyslu.

    Uz jsem to tu rikal, ve stavebnictvi i v automobilovem prumyslu jsou zavedene standardy, takze jednotlive dily jsou zamenitelne, protoze splnuji dane rozmery. Ve svete programovani tomu odpovida, ze dana knihovna implementuje jasne dane rozhrani nebo specifikaci, a to plati pro minimum veci.

  • 20. 5. 2018 17:07

    Filip Jirsák

    A jak toto prispiva do diskuze o znovupouzivani kodu a knihoven? Zaprve, myslel jsem, ze se tu nebavime na urovni integrace systemu, ale bezne tvorby programu, tj. implementace parseru, tridici algoritmu, apod.
    Psal jste, že ve vývoji softwaru je většina věcí atyp nebo unikát, a že málokdy najdete přesně odpovídající knihovnu. Tak jsem napsal několik příkladů standardů, které se běžně používají, a pro které je málokdy dobrý nápad psát si vlastní knihovnu. Nepsal jsem o žádné integraci systémů, ale o běžné tvorbě programů – pokud budete hledat dnes nejčastěji používanou technologii v programech, bude to nejspíš právě HTTP.

    Zadruhe, XML nebo JSON a protokol HTTP jsou jen formaty a protokol pro vymenu dat a neresi problem, ze aplikace ma data ve formatu ctverecku a protokol vyzaduje format kolecka.
    Já jsem nepsal, jaký to řeší problém. Jenom jsou ty formáty typický příklad toho, kdy vezmete hotovou knihovnu a použijete ji – a je jen velmi málo případů, kdy by bylo rozumné místo použití knihovny si psát vlastní XML parser nebo HTTP klienta.

    Uz jsem to tu rikal, ve stavebnictvi i v automobilovem prumyslu jsou zavedene standardy, takze jednotlive dily jsou zamenitelne, protoze splnuji dane rozmery. Ve svete programovani tomu odpovida, ze dana knihovna implementuje jasne dane rozhrani nebo specifikaci, a to plati pro minimum veci.
    A to XML, JSON, HTTP, to je co? To nejsou zavedené standardy? To neumožňuje, že jeden program parsující XML nahradíte jiným programem parsujícím XML?

  • 20. 5. 2018 21:10

    ded.kenedy (neregistrovaný) ---.v4.cust.lemointernet.cz

    Tak jsem napsal několik příkladů standardů, které se běžně používají, a pro které je málokdy dobrý nápad psát si vlastní knihovnu.

    Sorry jako, ale tento myslenkovy pochod jsem z predchozich prispevku opravdu neodhalil...

    A to XML, JSON, HTTP, to je co?

    To jsou tri low-level priklady pro nez existuje specifikace. Jsou to spise vyjimky, kam bych treba jeste pridal JEE, ale z toho nejde delat zavery a stavu celeho odvetvi.

    Uz z logiky veci (na rozdil od sveta fyzickych veci) nema prilis smysl mit vice vyrobcu jedne identicke (identicky chovajici se) veci. Ano, jsou vyjimky a jsou duvody, treba licencni, ale opet jich neni mnoho.

  • 20. 5. 2018 21:47

    Filip Jirsák

    Řeč byla o knihovnách, původně v souvislosti s parsováním. Pokud dneska aplikace něco potřebuje parsovat, bude to nejčastěji právě HTTP, pak JSON, XML a další různé YAMLy a INI atd. Občas se někdo rozhodne, že si pro takové použití napíše ručně parser a vytvoří vlastní formát, což je k vzteku pro všechny, kdo to pak musí používat a spravovat. A ten ručně napsaný parser není v ničem lepší, než kdyby autor použil nějakou knihovnu, právě naopak.

  • 20. 5. 2018 23:11

    ded.kenedy (neregistrovaný) ---.v4.cust.lemointernet.cz

    Řeč byla o knihovnách, původně v souvislosti s parsováním

    Tak to su klidny. Protoze, pokud mame knihovny na parsovani XML a JSON a k tomu protokol HTTP, tak

    doba, kdy bylo v IT vše atyp, je naštěstí už dávno pryč.

  • 20. 5. 2018 14:12

    Kiwi (neregistrovaný) 46.13.196.---

    Nebrojím proti knihovnám a generátorům! Brojím proti názoru, že pokud na něco existuje nějaká knihovna nebo generátor, tak že je _vždy_ výhodnější je použít. Tak totiž vyzněl ten první příspěvek, na nějž jsem reagoval. "Na to existuje knihovna - měli ji použít. Na to existuje generátor, měli ho použít." To je prostě nesmysl. Nebudu ztrácet čas detailním studiem generátoru a vymýšlením, jak narovnat, co generátor naohýbal, když si to mohu napsat sám z jedné vody načisto. Nakonec napíšu méně kódu, navíc přehlednějšího a jsem s tím hotov rychleji, než s generátorem. Podobnou zkušenost mám (a zdaleka nejsem sám!) třeba s LaTeXem - přiohýbání nějakého makra dá často tolik práce, času a nervů, že napsat si jednoúčelově přesně to, co potřebuji, přímo v TeXu, je podstatně rychlejší a přímočařejší. Výchozí makro řeší sto padesát věcí, které se mě netýkají, ale ta sto padesátá první, kterou potřebuji, se kvůli tomu dostává za hranici možného.

    Psal jste sice cosi o profesionálech, ale přitom jste přesně popsal amatérský přístup - podřídit konstrukci dílům, které má k dispozici, při velmi omezených technologiích, jež má amatérský kutil ve své garážové dílničce. Profesionál se nebojí vyrobení odlitku nebo vyfrézování nestandardního závitu, pokud je to účelné pro danou funkci. Z dílů stavebnice Merkur se dá postavit ledacos - třeba plotter - a stačí k tomu akorát šroubovák a klíč. Podle Vás by tedy profesionál takovou věc měl stavět zásadně z Merkuru nebo něčeho podobného, jen aby "nevynalézal znovu" V-profily, osičky, ploché profily, plechy atd.

  • 20. 5. 2018 14:32

    Filip Jirsák

    Pokud knihovna nedělá to, co potřebuju, neplatí podle mne tvrzení „pokud na to existuje knihovna“. Na přizpůsobení se požadavkům knihovny není nic špatného, často to pomůže výrazně urychlit vývoj a ušetřit náklady při vývoji i při údržbě – protože ty požadavky jsou často malicherné a zbytečné. Jistě, architekt si může vymyslet, že postaví dům z cihel atypických rozměrů – ale pokud je to jenom rozmařilost nebo dokonce fakt, že neví, jak vypadá běžná cihla, nezíská tím vůbec nic, akorát celou stavbu prodraží. Případy, kdy neexistuje žádná vhodná knihovna samozřejmě nastávají, ale dějou se mnohem méně často, než že knihovna existuje, ale kvůli NIH syndromu je potřeba si to napsat sám – a skončí to daleko hůř, než kdyby se použila nějaká existující knihovna. Ono totiž nejde jenom o to, kolik v daném okamžiku napíšete kódu, ale také o jeho údržbu a rozšiřování.

  • 22. 5. 2018 17:01

    belzebub (neregistrovaný) 82.142.76.---

    "Brojím proti názoru, že pokud na něco existuje nějaká knihovna nebo generátor, tak že je _vždy_ výhodnější je použít." - pak neumite cist, protoze to jsem NIKDE nenapsal. Zatimco Vy jste napsal ze "casto" je lepsi opak (tj. napsat si to sam.

    "Nebudu ztrácet čas detailním studiem generátoru a vymýšlením, jak narovnat, co generátor naohýbal, když si to mohu napsat sám z jedné vody načisto. Nakonec napíšu méně kódu, navíc přehlednějšího a jsem s tím hotov rychleji, než s generátorem." - ok, to je v naproste vetsine pripadu naprosta hovadina, navic na vsech frontach (rychlejsi - lol, prehlednejsi - lol, mene kodu - lol). Kdyby to tak bylo, tak by temer nikdo zadne generatory a frameworky nepouzival. To je cely SMYSL generatoru, aby to bylo rychleji, aby se napsalo VYRAZNE mene kodu a abych si mohl byt jisti ze je to spravne, protoze generator neudela chyby ktere udelam ja rucne.

    "Podobnou zkušenost mám (a zdaleka nejsem sám!) třeba s LaTeXem - přiohýbání nějakého makra dá často tolik práce, času a nervů, že napsat si jednoúčelově přesně to, co potřebuji, přímo v TeXu" - ale tady prave narazime na to Vase nepochopeni me kritiky - ja nikdy netvrdil ze NIKDY neni lepsi si to napsat sam. Ale tvrdim, ze ve VETSINE pripadu je lepsi si to sam nepsat. Napr. ja jsem v latexu napsal desitky dokumentu, manualu, dopisu, prezentaci (beamer) a i diplomku - a jenom asi ve 2 pripadech jsem musel resit ze bych chtel neco co latex neumi . Opet, VETSINA pripadu pouziti latexu staci. A o tom se bavim o VETSINE pripadu, pro ktere jsou ty "knihovny, frameworky, generatory, apod." urcene - pro reseni BEZNYCH, opakovane se opakujicich situaci, ktere NEMA cenu resit manualne.

    "Psal jste sice cosi o profesionálech, ale přitom jste přesně popsal amatérský přístup - podřídit konstrukci dílům, které má k dispozici, při velmi omezených technologiích, jež má amatérský kutil ve své garážové dílničce. Profesionál se nebojí vyrobení odlitku nebo vyfrézování nestandardního závitu, pokud je to účelné pro danou funkci." -lol - to si vazne myslite ze profesional je definovan tim ze si zamerne komplikuje praci? Pokud neni nejaky specialni duvod (a vetsinou neni), proc pouzit normalni normovany sroub, tak se pouzije normovany sroub. Tady nejde o zadny "strach", ale o to, ze profesional, v prvni rade, dela neco za PLAT. A nikdo mu nezaplati, ze misto obycejnych M8x50 frezoval vlastni srouby, nebo ze misto 2 beznych normovanych fitinku vyrabel model, formy a odleval si vlastni odlitky (navic naprosta vetsina strojnich firem dnes nema svoji slevarnu). Zakladni pracovni pomuckou KAZDEHO profesinala ve strojarine jsou normy, katalogy ozubenych kol, lozisek, apod. Protoze profesional vi, ze i kdyz stavi 5d obrabeciho robota, tak ty loziska, motory, srouby, tesneni a kabely vyrobi lip jini profesionalove.

    Mozna si myslite ze "profesional" znamena "clovek co dela vsechno sam, protoze je nejchytrejsi na svete", ale ve skutecnosti je to clovek, co se danou veci zivi - je to jeho PROFESE. A jenom malokdo se uzivi tim, ze bude delat veci, ktere uz existuji znovu, zvlast kdyz nejsou kriticke pro to co dela.

    ".. Merkuru nebo něčeho podobného, jen aby "nevynalézal znovu" V-profily, osičky, ploché profily, plechy atd." - jak jsem psal, profesional ve strojarine ma katalogy a normy a v nich si ty "V-profily, osicky, ploche profily, plechy atd" najde. Protoze i kdyz muze prijit situace, ze bude potrebovat neco, co zadny znamy vyrobce nedela (a i pak je lepsi mu zavolat jestli nemuzou neco co maji dodat v jine specifikaci), obrovska vetsina veci se da vyrobit bud uplne z hotovych dilu nebo polotovaru.

    Takze mozna jsem podle Vas straspytel, co se boji XML, coz me ale netrapi, a misto toho abych se nechal vyhodit za to, ze jsem mesic (spis teda rok..) nedelal nic jineho nez psal XML parser, a nic z toho co mam neni hotove.

  • 22. 5. 2018 23:47

    Kiwi (neregistrovaný) 46.13.196.---

    Ta strojařina asi přeci jen nebyla zvolena nejšťastněji za analogii. Jednak se v ní evidentně vůbec neorientujete a jednak situace v IT je opravdu úplně jiná. K tomu prvnímu - zkuste si někdy rozebrat libovolný stroj a roztřídit součástky na ty standardizované a na "originály". Na první hromádce budete mít leda tak šroubky a matičky. A k tomu druhému - kdyby strojař postupoval jako ajťák, tak místo osobního auta postupně vytvoří samohyb ve stylu Pat a Mat, který váží asi tak 200 tun, žere kubík benzínu na 100 km, potřebuje pro sebe šestiproudou dálnici, občas mu sama od sebe zhasnou světla, občas se při vyhození levého blinkru zastaví, když na něj zezadu někdo zatroubí dvakrát krátce a dvakrát dlouze tak náhle změní směr a tisíc podobných závad. Ale pravdu máte v tom, že dokud bude růst počet šestiproudých dálnic, benzín bude stát desetinu haléře a dále zlevňovat a lidem nebude vadit v čem to vlastně jezdí, tak z ekonomického hlediska je ajťácký přístup v pořádku. Ovšem z toho inženýrského hlediska bych byl mnohem opatrnější - pozastavovat se nad tím, proč někdo vymýšlí speciálně tvarovanou nádrž na motorku (a tedy - podle Vás - "znovuobjevuje nádobu na kapalinu"), aby optimálně využil prostor a k jednotlivým částem motoru byl pohodlný přístup, když tam přece může vrazit plastový patnáctilitrový barel jen proto, že ho má zrovna po ruce, to už se obhajuje hůř. Bastlíř (amatér) se spíše spokojí s tím, co je k dispozici, nežli inženýr (profesionál), protože mu jde v první řadě o to, aby to vůbec aspoň nějak fungovalo, a těch momentů, kdy profesionál zvažuje řešení přesně šité na míru danému problému, je mnohem víc, než si amatér představuje. Nedělá to, protože by neznal typizovaná řešení, ani protože by měl času na rozdávání, ale protože řešení na bázi typizovaných komponent nepovažuje pro daný problém za daných podmínek za optimální.
    Z IT se postupně stala těžká bastlířina, která má s inženýrskou prací pramálo společného.

    Tím bych asi tuto debatu skončil, kdo chtěl tak pochopil, co se mi nelíbilo na paušálním odsouzení "netypického" řešení jen kvůli tomu, že je netypické, a proč jsem přesvědčen o tom, že není kolo jako kolo.

  • 23. 5. 2018 7:28

    Filip Jirsák

    Vývoj software v dnešní době ale z velké části neodpovídá tomu vytvořit model motorky, která se pak bude prodávat v desetitisícových sériích. Spíš je to vzít kostru motorky, a na ni dát kola, řídítka, sedlo, kapotu a logo podle přání zákazníka. Podívejte se, kolik je firemních webů, eshopů, ERP systémů, kalendářů nebo her v mobilech – to dělá to množství používaného softwaru, ale zároveň to není nic, kde byste musel vymýšlet speciálně tvarovanou nádrž, protože nádrží na tuhle kostru už máte na výběr patnáct a akorát si vyberete tu, která se vám hodí nejlépe.

    To, že je nějaké řešení netypické, je opravdu jeho výrazné mínus. Což ale neznamená, že v některých výjimečných případech plus takového řešení nepřeváží.

  • 23. 5. 2018 12:26

    Kiwi (neregistrovaný) 46.13.196.---

    1. Jen do toho. Předchozí diskutér tvrdí, že strojař tak skutečně postupuje - ukažte mi tedy nějakou takto navrženou motorku. A připomínám, že diskutujeme pod článkem, který se netýká žádného softwaru na zakázku, jako jsou eshopy, weby apod.

    2. Čím komplexnější komponenta, tím více má parametrů a tím větší je pravděpodobnost, že některé nebudou plně vyhovovat požadavkům. Amatér použije, co má, i za cenu zhoršení požadovaných výsledných parametrů. Profesionál zváží - i s přihlédnutím k nákladům, zda jde použít to, co je k dispozici, a když ne, tak chybějící komponentu vytvoří (nebo zadá nějakému specialistovi). Opakuji po několikáté a naposledy, že když někdo koukne pod kapotu motorky a řekne "hm, motor si vyvinuli sami - to je automaticky špatně, protože existuje spousta motorů do motorek", tak je to projev fachidiotismu. Může to být špatně, ale pravděpodobnější je, že pro to konstruktéři měli dobrý důvod. Jinak by tam nějaký hotový motor samozřejmě bývali dali.
    A stejně tak si spousta programátorů raději napíše vlastní parser, přestože na ně existují generátory. Mezi námi, takový generátor se prakticky hodí tak na zpracování nějakého datového formátu nebo protokolu, a to ještě jen když se s tím nechci moc patlat, ale ne na zpracování reálného jazyka. Například mnou dříve uvedené nedostatky generovaného parseru jsou všeobecně známy - to, že tu nějaký Brouk Pytlík tvrdil, že to není pravda, jen dokazuje, že o tom nic neví a zkoušel si v tom dělat leda tak nějaký triviální učebnicový příklad ze zvědavosti - jestli vůbec.

  • 24. 5. 2018 18:35

    Filip Jirsák

    Jasně jsem uvedl, proč se vývoj software liší od vývoje sériově vyráběné motorky. Takže když to budete i nadále srovnávat, aniž byste vyvrátil mé tvrzení, v čem se to liší, opravdu mne nepřesvědčíte.

    Už dávno nediskutujeme o SQL parseru 602SQL Serveru, ale o obecném principu NIH. Proč nebyl použit generátor parseru u 602SQL Serveru je snad jasné a nevím, proč je potřeba to opakovat – za prvé v té době potřebný použitelný generátor s licencí použitelnou v komerčním produktu snad ani nebyl k dispozici, zda druhé SQL je dost svérázný jazyk a jeho gramatika nebývá vytvořena s ohledem na to, aby na něm dobře fungovaly generátory parserů.

    Jinak u komplexních komponent většinou nabývá na důležitosti ta komplexita a konkrétní parametry na důležitosti ztrácí. Profesionál se zabývá především tím, co je jeho specializací, a použije k tomu už hotové komponenty, i když nejsou dokonalé. Takže třeba vývojář databázového systému (třeba PostgreSQL) použije pro implementaci XML do databáze už hotovou libxml – protože on je dobrý v psaní databáze, ale v psaní XML parserů je průměrný. Tím, že si všechno spatlá sám v průměrné či podprůměrné kvalitě se vyznačuje amatér, profesionál dělá to, v čem je dobrý, a ostatní si nechá udělat zase od jiných profesionálů.

  • 24. 5. 2018 20:03

    Kiwi (neregistrovaný) 46.13.196.---

    Reagoval jsem na konkrétní příspěvek a celou dobu ho mám na mysli.
    Sám jsem napsal, že situace ve strojírenství je jiná než v IT - viz výše. Sám jsem napsal, že profesionál si případně danou komponentu zadá specialistovi - viz výše. Dokonce bych řekl, že přestože každý profesionál by měl mít základní přehled o své profesi a tedy by měl být schopen si danou komponentu nějak navrhnout, neměl by se do toho pouštět, pokud cítí, že na to existují jiní specialisté a že on sám optimálních parametrů nebude schopen dosáhnout.
    S čím jako inženýr zcela zásadně nesouhlasím, je to, že když jde o komponentu, ohledně níž nejsem specialista, tak že mohu použít první bazmek, který najdu, i když není dokonalý - jak píšete vy. To je amatéřina a ne profesionální práce! Hledám komponentu, která s ohledem ke svým parametrům, včetně ceny, podpory, autority, jež za ní stojí, autorům, spolehlivosti, testovatelnosti apod. bude vyhovovat co nejlépe. Nepošlu do kytek výkon nebo si neudělám bezpečnostní díru či jiné slabé místo do svého softwaru jen kvůli tomu, že s danou komponentou nechci ztrácet čas a neumím to. Nemusím být expert v oblasti, jaké se ta komponenta vnitřním fungováním týká. Ale pokud jsem se rozhodl ji použít, musím rozumět alespoň jejím vnějším parametrům.
    Pokud lepíte svůj software z komponent, o nichž víte, že nejsou pro daný účel dokonalé, postupujete amatérsky. Nevěšte hlavu, tak dnes postupuje většina vývojářů v IT - a podle toho to vypadá a zákazníci jsou s tím většinou srozuměni. Tím "pro daný účel" je myšleno to, že nepotřebuji hledat tu nejlepší logovací komponentu, když jde jen o nějaké mé ladící potřeby. Ale rozhodně se nespokojím s nějakou pomalou/příliš složitou/příliš jednoduchou/příliš náročnou/nespo­lehlivou knihovnou, pokud to má vliv na požadované výsledné vlastnosti toho, co vyvíjím. Tak například budu-li psát software na Monte Carlo výpočet, nejprve zhodnotím použitelnost generátoru pseudonáhodných čísel ve standardní knihovně a pak budu hledat nějaký lepší. Může se stát, že půjde o nějakou specialitu a nenajdu žádný vhodný. Pak zvážím, zda jsem schopen napsat vlastní sám, nebo budu hledat někoho, kdo to pro mě udělá. Ale rozhodně se nesmířím s tím, že ten standardní není dokonalý a já nejsem expert na psaní generátorů pseudonáhodných čísel, když na jeho kvalitě stojí kvalita celého výsledku, resp. to může mít na kvalitu mého produktu negativní vliv.

  • 24. 5. 2018 21:20

    Filip Jirsák

    mohu použít první bazmek, který najdu, i když není dokonalý - jak píšete vy
    Já jsem ale nic takového nepsal. Já jsem napsal, že použije už hotové komponenty – a tím se automaticky myslí, že ty komponenty řeší daný problém. Dokonalé opravdu být nemusí.

    Hledám komponentu, která s ohledem ke svým parametrům, včetně ceny, podpory, autority, jež za ní stojí, autorům, spolehlivosti, testovatelnosti apod. bude vyhovovat co nejlépe.
    Přesně tak. To ale vůbec neznamená, že by ta komponenta byla dokonalá.

    Nepošlu do kytek výkon nebo si neudělám bezpečnostní díru či jiné slabé místo do svého softwaru jen kvůli tomu, že s danou komponentou nechci ztrácet čas a neumím to.
    Jistě. A stejně tak nebudu trávit čas hledáním jiné komponenty, nebo dokonce psaním nové, abych v několikahodinovém zpracování dat ušetřil jednu milisekundu.

    Pokud lepíte svůj software z komponent, o nichž víte, že nejsou pro daný účel dokonalé, postupujete amatérsky.
    Já jsem ale nepsal, že nejsou pro daný účel dokonalé. Psal jsem, že nemusí být absolutně dokonalé, obecně dokonalé.

    Ale rozhodně se nespokojím s nějakou pomalou/příliš složitou/příliš jednoduchou/příliš náročnou/nespo­lehlivou knihovnou, pokud to má vliv na požadované výsledné vlastnosti toho, co vyvíjím.
    Jistě. Ale někdy také platí, že z trojúhelníku cena – čas – vlastnosti se obětuje něco z těch vlastností, a použije se nějaká knihovna, která by se normálně nehodila, ale důležitější je, aby to fungovalo alespoň nějak a včas.

    Může se stát, že půjde o nějakou specialitu a nenajdu žádný vhodný. Pak zvážím, zda jsem schopen napsat vlastní sám, nebo budu hledat někoho, kdo to pro mě udělá.
    Ale to je něco podstatně jiného, než co bylo v původním komentáři. Ten totiž vyzníval přesně v duchu: „Nějaký generátor pseudonáhodných čísel? To přece zvládnu napsat sám za půl dne.“ Což je bohužel stále častý případ, a mnohem častější, než že by někdo použil nevhodnou knihovnu. Spousta vývojářů neví ani co mají dostupné ve standardní knihovně a píšou si to znova sami.

  • 25. 5. 2018 0:46

    Kiwi (neregistrovaný) 46.13.196.---

    Tak to je asi nedorozumění. Tou dokonalou jsem měl na mysli optimální pro daný účel, tj. i s ohledem k těm dalším parametrům, jež jsem uváděl. Neboli - aby nebyla zbytečně méně kvalitní. "Dokonalý" jakožto sémantický superlativ v kvalitativně-funkčním smyslu by byl dost abstraktní a odvážný pojem. Asi dvakrát jsem zdůraznil, co jsem měl na mysli, dokonce i typograficky.

    aby to fungovalo alespoň nějak a včas. - Tak to už je ale nouzové řešení. To se dělá, když už něco hoří a mělo by jít opravdu jen o výjimečné situace, jež by rozhodně neměly být považovány za standard. Bohužel, v IT to standard je.

    Ale to je něco podstatně jiného, než co bylo v původním komentáři. - Původní komentář byl ten, na nějž jsem reagoval a u něhož (nebo se mi to tak aspoň jeví) se shodneme, že dělat parser SQL pomocí generátoru bylo v tehdejší době asi nereálné (podle mě stále je), a že tedy kritika v tomto bodě nebyla na místě. Polemizoval jsem tu s názorem, že není důvod psát ručně parser, když máme generátory, a zobecnil jsem to na jakoukoli komponentu. Demonstroval jsem tu na několika příkladech a analogiích, že nejdostupnější řešení nebývá to optimální - tvrdím, že je to poměrně častý případ, bylo mi oponováno, že je to spíše výjimečný případ. Asi máme každý jiné zkušenosti, nároky nebo jsme jinak kritičtí.

    Spousta vývojářů neví ani co mají dostupné ve standardní knihovně a píšou si to znova sami. - Je třeba rozlišovat, že nevědí, že to mají v knihovně, a že to vědí, ale nevyhovuje jim to. Naposledy opakuji, že na toto jsem celou dobu narážel, protože v tom prvním komentáři se toto nerozlišovalo - "chybí zdroj pro yacc, tedy autoři si psali parser sami, tedy je to řešeno nevhodně". Tedy nešlo o blíže nespecifikovanou "spoustu vývojářů", ale o vývojáře produktu, o němž je článek. Kdybych měl hodnotit práci "spousty vývojářů" zcela obecně, jak jsem měl možnost se s ní setkávat zejména v poslední době, tak bych jim vzkázal cimrmanovské "neprogramujte to - a pokud možno, neprogramujte vůbec", přičemž tendence je rok od roku horší a horší. Příliš často se střetávám s názorem "nejde to vygooglit, tak to neexistuje" nebo "není na to knihovna, tak to nejde"/"je na to knihovna, tak nad tím nebudu více přemýšlet". Mám rád takovou tu "kreativní" lenost, která vede k elegantním řešením. Nesnáším ale lenost používat hlavu, co vede k fušerství.

    Tím bych se rozloučil, protože už tu akorát opakuji dokola dříve řečené a lépe to říci už asi nedovedu. Takže pokud je to stále nesrozumitelné, tak sorry.

  • 25. 5. 2018 9:33

    Filip Jirsák

    Původní komentář byl ten, na nějž jsem reagoval a u něhož (nebo se mi to tak aspoň jeví) se shodneme, že dělat parser SQL pomocí generátoru bylo v tehdejší době asi nereálné (podle mě stále je), a že tedy kritika v tomto bodě nebyla na místě.
    Na tom se shodneme.

    Polemizoval jsem tu s názorem, že není důvod psát ručně parser, když máme generátory, a zobecnil jsem to na jakoukoli komponentu.
    Já jsem ten názor chápal tak, že k ručnímu psaní parseru musí být velmi dobrý důvod, standardní volba by měla být použít generátor, a teprve když se ukáže, že to fakt nejde, uvažovat o ručně psaném parseru. A s tím souhlasím. Ano, existují výjimky, jako např. právě nutnost držet zpětnou kompatibilitu až někam do středověku, což je případ třeba Oracle SQL. Ale první volba by měla vždy být použít už hotové řešení.

    Demonstroval jsem tu na několika příkladech a analogiích, že nejdostupnější řešení nebývá to optimální - tvrdím, že je to poměrně častý případ, bylo mi oponováno, že je to spíše výjimečný případ.
    Optimální (nejlepší) nebývá nic, ale ono stačí, když to splňuje podmínky – a pak je vhodné z dostupných variant vybrat tu (relativně) nejlepší. Vzhledem k tomu, že do kritérií řadím i čas vývojáře, bývá málokdy lepší programovat něco svého, když už řešení pro daný problém existuje.

    Je třeba rozlišovat, že nevědí, že to mají v knihovně, a že to vědí, ale nevyhovuje jim to.
    Já jsem psal o prvním případu, se kterým se setkávám.

    Naposledy opakuji, že na toto jsem celou dobu narážel, protože v tom prvním komentáři se toto nerozlišovalo - "chybí zdroj pro yacc, tedy autoři si psali parser sami, tedy je to řešeno nevhodně".
    Ano, ale v tomto případě byla chyba v tom, že se dotyčný nezamyslel nad tím, zda se náhodou nejedná o tu výjimku, kdy použití hotového řešení není nejlepší volbou.

  • 21. 5. 2018 15:29

    Ravise (neregistrovaný) ---.102.wms.cz

    > Abych se vratil k Vasemu autu: loziska, srouby (mozna krome ojnicnich), matice, podlozky, tesneni, apod. - pokud cokoliv z toho nejaky inzenyr navrhne vyrabet, misto koupit hotove, tak bude za blbce.

    Jasně, normovaný součástky. Ve světě software bych to připodobnil k jsonu, http/s, TCP/IP a podobně. Standardizovaný pojivo mezi tím, co navrhne inženýr. To jest karoserie, blok motoru, kliková hřídel...

    Zkus si třeba frézováním/sou­stružením/vrtá­ním do kusu plechu vyrábět pikslu od holící pěny. Blbost. Zvolíš jinej polotovar (tyč dvacítku?), jinej technologickej postup (protlačování), když budeš dělat jo velkou sérii, necháš si udělat ad hoc přípravky a nástroje. Protože snažit se používat univerzální nástroje tě vyjde dráž, než si zaplatit výrobu nástroje na míru. Nebo třeba kontrola těch podložek. Myslíš si, že na konci pásu "sedí bába se šuplerou", nebo že bábě dali do ruky na míru udělanej kalibr?

    Jak jedna tak druhá extrémní cesta - používat hotový knihovny na všechno vs. psát všechno sám na zelený louce - jsou cesty do pekel. Dobrej inženýr (ať už strojní nebo programátor) dokáže říct "stop, dělat to takhle je blbost".

  • 18. 5. 2018 21:02

    backup (neregistrovaný) ---.dip0.t-ipconnect.de

    ....hlavně u lidí, kteří napsat parser prostě neumějí ...

    Brian Kernighan v knize Masterminds of Programming (2009 O'Reilly) vypravi o tom, jak yacc nesmirne prispel k rozvoji ve vyzkumu jazyku. Rika:

    ja sam bych nikdy nedotahl zadny jazyk do konce, kdybych nemel yacc. At uz z jakychkoliv duvodu, ja jsem proste nebyl pro psani rekurziniho sestupneho parseru dost dobry. Mel jsem vzdycky problemy s prioritami a asociativitou. U yaacu nad tim nemusite premyslet.

    Jinak souhlas s tim, ze to soft. inzenyrstvi je o tom, podle okolnosti spravne rozhodnout.

  • 18. 5. 2018 12:24

    Kamil Zmeškal
    Bohužel, co se týká Oracle Express, tak to je prakticky mrtvé. Oracle na to z vysoka kašle, proti MS SQL Express se to nedá srovnávat. Hlavní nevýhody:
    • nevychází na to žádné patche, ani bezpečnostní (na rozdíl od MS na to "nepasuji" patche pro normální verze)
    • vydané verze jsou od sebe strašně dlouho (verze 10.2 z roku 2007, pak až 11.2 z roku 2014 a od té doby nic)
    • nepodporuje (ofiko) Windows 10
    • chová se to, co se týká instalace a administrace, trochu jinak než "velký Oracle", není to jako u MS, kterému prakticky fungují všechny nástroje na všechno (nechytejte mě za slovo), jen ořezané co se týká výkonu
  • 21. 5. 2018 17:42

    Karel (neregistrovaný) ---.cust.nbox.cz

    XE není mrtvé, XE je jednorázovka. Když je edice stabilní, tak Oracle dá pár lidí na XE. Ti to připraví a otestují, pak se to vydá a ti lidé jdou zase zpátky. Dokud se daná edice ladí a vyvíjí, tak se na XE nepracuje. A jakmile se XE vydá, tak se na ní pak už taky nepracuje. To není plnohodnotná verze, to je prostě odladěný "snapshot" ořezaný o věci co to nepotřebuje a předkonfigurovaný do té míry, že s tím dokáže pracovat běžný pracovník IT.

    Proto se na XE 12c začalo pracovat až nedávno (pokud se tedy už začalo), proto ani na ní pak nebudou žádné patche a také proto je to tak strašně ořezané. To poslední je ale spíš výhoda, ona plná verze je pro nezkušeného DBA past vedle pasti. Nástroje typu DBCA to sice dost zjednodušily, ale i tak z nezkušených IT lidí padají instance, které prakticky nejde zálohovat, případně po pár měsících samy zhavarují na věci typu "aha, ale oni v popisu db_recovery_fi­le_dest_size nepsali, že mám čas od času nějaké soubory mazat?"

    Jo a ještě jedna věc: ony jsou plné edice pro vývojáře za určitých podmínek zdarma (viz OTN). Na to se také trochu zapomíná a s XE se pak potýkají lidé, kteří by mohli klidně použít SE a dopřát si pár vytrhaných vlasů při její konfiguraci.

  • 18. 5. 2018 12:41

    Severák (neregistrovaný) 89.203.221.---

    tyhle historický články jsou zajímavý, těším se na další

  • 18. 5. 2018 13:07

    Zdenek (neregistrovaný) 185.17.212.---

    V téhle databázi jsem naprogramoval kompletní systém pro řízení agendy školy (vysvědčení, slovní hodnocení, databáze žáků, ..., později intranet pro žáky a rodiče). S nostalgií na těch cca 8 let fungování vzpomínám.

  • 18. 5. 2018 13:20

    skov

    Já jsem skončil u poslední použitelné verze 602SQL8, verze 8.1c (build 6) z roku 2008. Dodnes není problém v tom prostředí naprogramovat použitelnou databázovou aplikaci včetně GUI. Chybí bohužel jen to nejdůležitější - podpora výrobce. Instalátor o velikosti 11 MB (ano pouze 11 MB ;) běží na všech verzích OS Windows počínaje 9X konče 10 a obsahuje kompletní prostředí pro okamžitý vývoj aplikací včetně nápovědy. Rozhodně doporučuji vyzkoušet to, co programátorský team kolem Januše Drózda, Vítězslava Boukala a Václava Pecůcha dokázal vyrobit.

  • 18. 5. 2018 15:31

    r.u.r. (neregistrovaný) ---.seas.sk

    tiez som v tom cosi naprogramoval, a otravoval Honzu Simu, aby nieco upravili ako chcem. Posledny moj pocin ma 5 rokov (a stale bezi).

  • 18. 5. 2018 19:15

    Filip Jirsák

    602SQLServer mne naučil číst potvrzovací dialogy. Při mazání celé databáze se objevil velký potvrzovací dialog, zda chci databázi opravdu smazat, že je to nevratná operace. To jsem věděl. Jednou jsem něco testoval, skončil jsem a chtěl jsem databázi smazat – a už jak jsem na to mazání klikal, problesklo mi hlavou, že vlastně chci otestovat ještě něco a databázi smazat nechci. Naštěstí je tam přece ten potvrzovací dialog, okamžitě jsem byl myší připravený na pozici pravého tlačítka dialogu (tenkrát byl na Windows standard, vlevo tlačítko „Ano“, případně „OK“, vpravo „Ne“ nebo „Storno“), připraven zrušit mazání hned, jak se dialog objeví – asi aby si to databáze náhodou nerozmyslela a nesmazalo to i bez potvrzení. Byl jsem fakt rychlej, ten dialog se skoro ani nestihl zobrazit. Akorát jsem zapomněl na to, že na tomhle jediném dialogu pro smazání celé databáze jsou tlačítka „Ano“ a “Ne“ prohozená, aby lidé automaticky neodklikávali „Ano“, ale opravdu tomu věnovali pozornost.

    Od té doby vím, že je hloupé všude alibisticky nasázet potvrzovací dialogy, protože uživatel si pak zvykne všechno dělat „dvojklikem“ – na akční tlačítko a pak bez přemýšlení na „Ano“. A když ho pak opravdu chcete na něco upozornit, potvrzovací dialog nefunguje. A taky vím, že je potřeba dávat pozor na to, že když chcete uživatele něčím překvapit, aby přemýšlel nenapáchal škodu, může taky napáchat škodu v důsledku toho překvapení.

  • 19. 5. 2018 8:22

    muf (neregistrovaný) ---.opera-mini.net

    Článek ve mně po dlouhé době vyvolal vzpomínku "z mládí.".
    Někdy v roce 1994(nedlouho po škole) jsme s kolegou hledali pro firmu tehdejšího zaměstnavatele náhradu nevyhovující souborové databáze poté, co testy s SQL serverem GUPTA naprosto selhaly(krátce - byl to nedodělek plný bugů).
    No a přes jeden kontakt jsme se dostali, jestli si to dobře pamatuju, v Praze na Novodvorskou do areálu VÚ A.S. Popova. Jednali jsme se dvěma lidmi z nichž jeden byl zmíněný Januš Drózd. Těšilo mě, že jsem osobně poznal člověka, kterého jsem znal ze stránek Mikrobáze a Bajtu...

    Nakonec to díky našim obchodníkům neklaplo a já krátce poté firmu opustil. Na Novodvorskou jsem ale v následujících létech poměrně často jezdil - tentokrát do Českého Telecomu, kde jsme pro zákazníka provozovali mašiny od Digitalu s Alpha procesory a Digital Unixem verze 3.2G.
    Datábází tady byl Informix 5 a 7 a to byla přece jen jiná liga... Na trápení s Guptou jsem rád zapomněl :-)

  • 19. 5. 2018 11:02

    ehmmm (neregistrovaný) 185.193.85.---

    Dekuji. Spolecne s PC Fandem z toho zacina byt zajimavy serial.