Fun with Microsoft (diskuse)

[xvasek]

Nevím, proč řešíš furt ten Oracle. Jako není to špatná databáze, ale všechny ty pasti okolo: uzavřenost, odkázanost na software, který Oracle certifikuje a v budoucnu může tento seznam kdykoli změnit, licenční politika atd. Vždyť je to úplná blbost.

Jinak osobně bych použil něco jako GraphQL, protože si myslím, že formát a struktura dat je pro danou aplikaci zcela zásadní. Kdo to má dobře, tomu stačí maličký aplikační serveřík a už to může fičet.

Frontend? Těžko říct, web je celkově OK, ale není na všechno. Teď jsem řešil, že jsem pomocí NCF potřeboval přečíst na android zařízení RFID kartu / čip. To buď přes web nejde, nebo to radši nechci vidět. Psal jsem teď frontend v kivy - je fajn, že je velmi multiplatformní, ale není fajn, že je designováno primárně pro touchscreen zařízení a obecně vypadá všude divně.

[Vantomas]

Web aplikaci zabalit třeba do Cordovy a tam už API pro NFC je dostupné...

[xvasek]

To je fakt. Hlavně žádné tlusté klienty, jak má vypdat a chovat se "okno" aplikace musí být definováno zcela na serveru.

[Max]

Oracle proto, protože ho máme a jsme na něm zaháčkovaný. Proto řeším Oracle.
Samozřejmě, pokud se použije v novém projektu ORM a přenese se zbývající logika, která je řešena na straně DB (v podobě PLSQL procedur, fcí apod.), tak následně už by nebyl přechod na jiný db backend bolestný. V současné a nejbližší době to možné není (člověk musí být realista).
Zdar Max

[trekker.dk]

V tom případě byste ale neměl Oracle prezentovat jako nevýhodu - jestli jsem vygooglil správnou dokumentaci, tak se to dá používat s ~ deseti dalšími DB. To, že jste se nechali zaháčkovat, není problém Microsoftu.

[Max]

To je jedna půlka problému, ta horší je, jak už jsem psal, že změnili druh vývoje a tlačí to zase jiný směrem.
Zdar Max

[Petr Tomášek]

Tak si najděte Guru Járu

[Bystroushaak]

Javu / Python. Podle typu projektu. Spíš ale ten py.

[Martin]

Co třeba zkusit CodeOnTime? Je to sice klikačka, ale při dobře navržené databázi to frontend vygeneruje samo.

Nebo se inspirovat u Odoo, ti jedou v Pythonu a rovněž mají boží systém na kterém se dá stavět.

[xsubway]

No a jak velký ten systém bude? Jak dlouho bude podporovaný? Jakou bude mít životnost, cyklus nasazování? Kolik vývojářů budeš potřebovat? Kde je seženeš? Jaká je křivka učení? Bude to běžet v režimu HA? Bezpečnost, suport, kritické chyby, kolik bude stát vývojové prostředí a další licence ... ?

Zřejmě těch otázek bude ještě více ...

[Max]

Support 20 a více let. Rozsah v podobě kontinuálního vývoje 8 programátorů po celou dobu. Programátory máme, vyvíjí aktuální IS ve VisualFoxPro, který již přestává splňovat aktuální požadavky.
HA, jasně, a musí to jít škálovat na všech vrstvách.
Vzhledem k rozsahu je cena vývojového prostředí zanedbatelná částka.
Vesměs se jedná o vývoj úzce zaměřeného IS pro vlastní firemní použití a řízení vnitřních procesů.
Nicméně pokud víme, že rozsah bude velký, na dlouhou dobu, tak je tlak na co nejmenší změny kvůli prostředí. Tj., nepřepisovat v čase životnosti projektu nějaké věci stále dokola kvůli tomu, že vyjde nová verze něčeho.
Zdar Max

[NN]

What? VisualFoxPro uz je par let mrtve nebo ne?

[Max]

Ano, samozřejmě, že je. Nicméně v roce asi 1995 se začalo na FoxPro s dbf soubory, někdy po roce 2000 se zmigrovalo (copy paste, co nefungovalo, to se přepsalo) na Visual FoxPro s Oraclem a od té doby se tam ládují fce a propojuje se to s hafec systémy (jak se SAPem, tak s DMS, tak pro komunikaci s různými EDI zprávami, odesílání a vybírání mailů, reporting atd. atd. atd.).
Tlustý VFP klient stále pod Win běží a není to zatím z pohledu podpory OS problém.
Kromě tedy problému se strukturou db je zde i problém s VFP. Tzn. řeší se, jakým způsobem se 23 let vyvíjený VFP projekt nahradí něčím, co by odpovídalo současným a budoucím požadavkům. Vývoj byl na začátku 2 osoby, v roce asi 2002 asi 5 osob a nyní to primárně vyvíjí asi 6 osob + další dělají věci kolem (celkem asi 10 vývojářů).
Zdar Max

[xsubway]

Možná mě pár lidí roznese ..., ale šel bych právě do Java EE a aplikačního serveru, který implementuje některé z Java EE standardů alespoň pro backend a na frontendu možná něco i mimo tyto standardy. Nebezpečí je, že na frontendu se tenchnologie mění co chvíli, takže těžko radit něco s životností delší než dva roky S .NET technologiemi nemám zkušenosti a ostatní jazyky, frameworky, atd. mají, podle mě, příliš malou podporu v business sféře.

[Odin1918]

S MS cim dale tim vetsi bida? Nu, radeji se podivej na jejich prijmy a zisky a pak mluv. Takovou bidu bych bral, protoze jsem zly clovek a myslim jen na sebe a sve penize.

[Max]

Myslím, že jsem se vyjádřil zcela jasně. Proč to překrucuješ? Nikde netvrdím, že se jim nedaří, cloud jim vynáší velký many.
Jasně jsem to vztahoval k tomu, že v ve spoustě věcí nemají jasný vize a aktuální stav je myslím dostatečným příkladem.
Cloud také okopírovali, přišli pozdě, ale dohnali zpoždění, stejně jako třeba dřív s xboxem. S revolucí v telefonech takové štěstí neměli, stejně jako u webových prohlížečů. C# se drží, ale jasně jsem v zápisku nastínil, jaký je aktuální stav, kde začali kopírovat node.js
Zdar Max

[Jendа]

Obzvláště ve světle nedávné série zápisků Oracle : dostáváme na prdel mi přijde neuvěřitelné začít ještě koketovat s Microsoftem.

Vlastně je to taková korporátní obdoba BDSM - firmy, které se rády nechávají trestat od jiných firem.

[Odin1918]

Ucinene moudro z hackerspacu Pokud to myslis s vyvojem IS opravdu vazne, nemas jinou moznost, nez stavet na resenich od MS, oracle ci ibm. Java z toho samoxrejme vychazi nejlepe. Moznosti jako node.js, ohp, python jsou irelevantni, jelikoz jsou urceny pro jine use cases.

[xkucf03]

+1

[Fluttershy, yay!]

korporátní obdoba BDSM

V konvenčním SSC BDSM jsou docela důležitá safewords. To asi nebude případ „korporátního BDSM“, že?

[Max]

Se nějak vyznáš :D
Zdar Max

[Fluttershy, yay!]

To jsou naprosto elementární záležitosti, kéž by o nich věděl každý – a nebyly omezeny na část komunity kolem BDSM. Možná by pak vypadala jinak situace s rozšířením sexuálního násilí, popř. kauzami jako vyhození Larryho Garfielda z Drupalu.

[Max]

Špatný pokus o vtip. Samozřejmě o safe words vím a myslím, že i většina lidí, co znám. Né, že by to byli vyznavači, ale prostě vědí.
Zdar Max

[Fluttershy, yay!]

To je jenom dobře. Teď ještě, aby to byla běžná praxe i v tom „korporátním BDSM“.

[Jendа]

Taky pravda.

[xkucf03]

Co byste dnes použili za technologie pro nějaký větší projekt...

O tomhle mám rozepsaný zápisek... ve zkratce: Java.

[johnyK]

ve zkratce: Java.

myslim , ze o tom zpiva Joan Osborne v tom svem svetovem hitu, ve kterem je myslim v refrenu

And yeah, yeah, Java is great
Yeah, yeah, Java is good
And yeah, yeah, yeah-yeah-yeah

[Max]

Tak šup, šup, dokončit :).
Zdar Max

[Michal2]

Mejdrive das +1 na prispevek, ktery hejti Oracle a pak doporucis Javu, tedy Oracle produkt. To musi byt nejaka schiza, nebo takovy ten druh amnezie kdyz zapominas co se se stalo pred nekolika minutami.

[xkucf03]

Java pochází od Sun Microsystems a je to programovací jazyk, který může implementovat kdokoli (existují různé implementace a ta hlavní/referenční je svobodný software). Zatímco Oracle DB je proprietární software od Oraclu.

[Bherzet]

může implementovat kdokoli

Ovšem pozor na patenty.

[Michal2]

Tohle vysvetleni neberu. Sun je uz 8 let v utrobach Oraclu. To je v IT takova doba, ze je irelevantni co bylo predtim. Take bych mohl zacit tvrdit, ze Java je system pouze pro domaci spotrebice protoze to byl puvodni Goslinguv zamer.

Jak si muze kazdy implementovat Javu si skuste popovidat s lidma z Googlu jak se kvuli tomu nemuseli ani trosku s Oraclem soudit.

Jedina implementace skutecne nasazovana v enterprise je ta od Oraclu.

Oracle ma Javu zcela v hrsti. Ale klidne si nalhavej dal ze tomu tak neni

[deda.jabko]

Jedina implementace skutecne nasazovana v enterprise je ta od Oraclu.

A ta od IBM ne?

FYI, jiz delsi dobu je referencni implementaci Javy OpenJDK.

Oracle ma Javu zcela v hrsti. Ale klidne si nalhavej dal ze tomu tak neni

Doporucuji nahlednou na JCP a na afiliace lidi, kteri stoji za jednotlivymi JSR.

[Bherzet]

Jak si muze kazdy implementovat Javu si skuste popovidat s lidma z Googlu jak se kvuli tomu nemuseli ani trosku s Oraclem soudit.

Jádro sporu AFAIK bylo v tom, že na mobilních platformách Javu (jako technologii) licencoval Oracle. Google je obešel tím, že reimplementoval API (mám za to, že jazyka jako takového se to netýkalo) a to je také jádrem onoho soudního sporu. Viz ten link, co jsem postoval (přiznám se, že jsem líný to číst celé).

Jinak Google také v minulosti vyvinul GWT, což je transkompilátor Javy do JavaScriptu. Je to open-source a Google sám na něm má postavené velké služby jako AdWords nebo Blogger. S tím žádné legální problémy nejsou.

Dále existuje GNU Classpath, neúplná implementace JRE 1.5. Z alternativních implementací celé JVM už jednu zmínil deda.jabko (dříve J9, nyní OpenJ9). Já se připojím s komerečním Excelsior JET a experimentálním/výukovým JamVM. V minulosti ještě třeba Apache Harmony (která byla původně použitá v tom Androidu).

Oracle ma Javu zcela v hrsti. Ale klidne si nalhavej dal ze tomu tak neni

Dobré shrnutí je tady. Kdyby Oracle chtěl začít trollit nejhorším možným způsobem, skončilo by to nejspíš forknutím posledního OpenJDK (očekával bych, že se toho zhostí třeba Eclipse Foundation nebo Apache Foundation) a bude se to udržovat. Nesmět z licenčních důvodů dělat změny v jazyce, pokud to správně chápu, tě nějak moc tankovat nemusí, když existují plně interoperabilní jazyky jako Scala nebo Groovy, a API rozšiřovat buď lze, nebo se nové věci mohou vyvíjet jako samostatná knihovna.

[Ondřej]

My děláme v NET core, a přijde mi to super volba. A naopak, přijde mi, že na vývoji se podílí docela dost přispěvatelů mimo MS, a myslím, že se jim to dost povedlo. Nějakou formu LTS mají, NET core 2.1 je LTS a bude podporován 3 roky.

[Max]

Pravda, koukám na to, 2.1 má slíbený LTS.
Otázkou je, zda se to hodí na nějaký komplexní škálovatelný ha backend? Na takovu věc si třeba Node.js moc neumím představit a .NET core je tomu hodně podobný.
Zdar Max

[Ondřej]

Já nemám zkušenosti s Node.js, my na to přecházíme z velkého .NET frameworku, Nemám zkušenosti ani s Oracle, používali jsem MSSQL, a teď kolegové experimentují s PostgreSQL, jestli by nám to nestačilo. Ale já to vnímám jen z pohledu juniora v malé firmě, ale lidi, kteří to opravdu vymýšlí jsou u nás NET Core nadšení též.

[Max]

Jo, nadšení některých lidí je velké, hlavně u performance testů oproti předchozímu .NET Frameworku.
A používáte nějaké ORM? Zajímaly by mně třeba nějaké performance porovnání s a bez ORM apod. Pokud jste tedy něco podobného řešili.
Díky
Zdar Max

[Ondřej]

Používáme Entinty Framework Core, bez ORM jsme snad nikdy nic nenasazovali

[Max]

Mno, v našem případě EF nefunguje moc rychle. Jsou tam brutální výkonnostní propady. Něco je ok, u něčeho to klucí vzdali a přepsali do SQL a místo 10min trvá akce v řádu sekund. Nevím, zda je to problém EF, nebo EF vs. né příliš ideální struktura db, nebo problém na straně programátorů.
Každopádně jedna kauza z minulé doby byla i v tom, že se nasadila změna do db (přidal sloupeček) a Entity Framework měl pak problém, dokud se mu neřeklo, aby si načetl novou strukturu. Do té doby na SQL kašlal a nedělal nad tabulkou update.
Zdar Max

[Ondřej]

My fungujeme metodou classes first a nejsem si jistý, jestli EF Core vůbec DB first umožňuje (EF6 ano) Takže ani nepočítáme s tím, že by se nám v DB objevil sloupeček navíc. Nicméně je pravda, že nás výkon DB na současném projektu vůbec netrápí, máme tam pár desítek transakcí za minutu. Doo budoucna se and těmi daty sice budou provádět nějaké oprace, ale ani tehdy to nebude nijak náročné nasazení. Reálně to budou maximálně jednotky milionů záznamů, které není potřeba zpracovat v řádu milisekund a dokonce ani sekund.

[Max]

Takže update k tomu výkonu. Hlavní vývojář, který má i někoho pod sebou, dělá s EF asi 4 roky a ukázalo se (po najmutí konzultanta, který má EF najetý), že neví, jak EF funguje. Používal tam různá volání, která způsobovala buď cyklické dotazy do db, nebo jiné cykly v rámci EF. Ve finále to tedy asi nebude šaptný ORM.
Osobně bych tedy byl radši, kdyby ten EF byl pomalý, než zjištění, že programátor 4 roky dělá něco, o čem neví, jak funguje :-/.
Zdar Max