Vývoj programu
Dobrý den,
nedávno jsem přišel na zajímavou chybu v trhu, kde by se hodil program, který doposud ještě není. Dlouho jsem nad tím přemýšlel a různě promýšlel, jak bych ho udělal. Jsem sice v IT oboru, ale programováním zatím doposud nedotčený. Měl jsem C# na střední, ale jen chvíli a špatného učitele, takže jako kdybych nic neměl. Pohybuji se spíš v oblasti SAPu a integrací.
Každopádně, rád bych se hecnul a začal se učit nějaký jazyk s tím, že bych měl jako cíl vytvořit ten mnou vymyšlený program. Potřebuji ale pomoct při začátku. Možná je toto špatný dotaz, ale rád bych se Vás zeptal, v jakém jazyce začít ? V jakém jazyce pak budu schopný napsat ten program ? C# ?
Vím že to nebude vůbec nic lehkého a nepočítám s tím, že do toho skočím a hned začnu dělat vlastní program. Samozřejmě do toho jdu s tím, že se to budu dlouho dobu učit. DĚKUJI ZA RADU :)
A co to bude za aplikaci? Desktopová, mobilní, webová? Pokud desktopová či mobilní, jakou platformu, či jaké platformy budeš podporovat? Na tom výběr jazyka dost záleží.
Díky za odpověď :) Měla by to být desktopová aplikace (windows), do budoucna zvažuji i nějakou lehčí mobilní verzi přímo pro uživatele, né pro firmu. Abych popsal přesněji a v nějaké příkladu tu appku-
(Bude mít dva vstupy, řekněme že je xxx druhů palet a např. 6 druhů kontejneru. Do appky člověk zadá jaké má všechny palety tzn. přesně nějaké druhy.. a appka už si podle druhu vytáhne z databáze palet její rozměry a váhu. Poté zadá jaký má kontejner, zase se vytáhne z databáze rozměry přimo toho kontejneru. A potém mu appka řekne jako výstup jestli se tam všechny palety co zadal vejdou, či ne a jestli to nepřesáhne povolenou hmotnost. V další fázi bych chtěl, aby appka řekla, jak přesně má palety poskládat tak, aby se to tam vešlo.
Ještě jednou díky za rady :)
Začni aplikací pro PC a tam klidně použij C#, který asi trochu znáš a budeš se v tom orientovat.
MS ale nemá multiplatformní jazyk, který by z jednoho kódu zkompiloval aplikaci pro Desktop i mobil.
Na druhou stranu budeš mít všechny algoritmy i práci s DB vyřešenou, takže pro mobil to pak přepíšeš do něčeho pro mobil. Tam pak musíš řešit i rozložení formulářů pro různá zobrazení (na výšku, na šířku), pro tablet...
Lazarus je multiplatformní, ale není to od MS. To snad není vada.
To stejné může použít Delphi community edition - multiplatformní a taky zdarma.
Ale on zná C# a potřebuje si ujasnit, co vlastně chce. Tak ať to klidně napíše v C#. Pokud se to chytí na Windows (a jestli to dotáhne do konce), pak může přemýšlet o dalších platformách.
C# je už pár rokov tak multiplatformný, že už viac sa asi ani nedá. Vieš v ňom robiť aplikácie pre desktop, pre web, pre mobily, prakticky všade. Každopádne ale riešiť multiplatformnosť, keď je platforma jasne daná, asi nemá veľký zmysel.
Takže napíšu program, upravim rozložení formuláře pro ruzna rozlišení a jen řeknu "zkompiluj mi to pro desktop" nebo "pro Android" a z jednoho zdroje mam exe nebo apk?
https://dotnet.microsoft.com/apps/xamarin/cross-platform
Když se tak koukám, tak to není úplně vizuální návrh formuláře, ale musím ručně editovat layout v XAML.
Myslel jsem standardní C# aplikaci, včetně design time návrhu formulářů, eventů atd. - třeba i pomocí nějaké vizuální multiplatformní knihovny
To pak vezmu a zkompiluju pro Windows, Android nebo MAC.
Takto to funguje?
To jde o to, čemu říkáš standardní C# aplikace. Návrh GUI pomocí XAML je v .netu standard už nějakých 10 možná 15 let.
WindowsForms, na které asi narážíš, je sice stále podporována varianta, ale už je trochu "legacy".
C# jsem teď dlouho nesledoval. Takže prostě s nějakou vizuální knihovnou navrhnu UI (formuláře) bez psaní kódu - nahážu controls na form a ten samý formulář pak můžu to použít jak pro Windows, tak i pro Android nebo MAC?
Tak to pokud vím není. XAML má sice (minimálně ve WPF) nějaký vizuální návrh, ale co jsem pozoroval, tak ho stejně většina lidí nepoužívá a píše rovnou XAML. Web se taky obvykle píše přímo v HTML i když existují nějaké vizuální nástroje.
Takže formy pro Windows, včetně obsluhy událostí atd. dělám zvlášť (vizuálně) formy pro android, včetně napojovani událostí píšu ručně, protože je to lepší. Pochopil jsem to správně?
Použiju jen aplikační kód, který je společný a vizuální část tvořím nezavisle pro kazdou platformu.
No pokud použiješ ty Xamarin.Forms tak je ani nezávisle tvořit nemusíš. Můžeš najednou vytvářet aplikaci schopnou běžet na Androidu, iOSu i Windows 10.
Ale formy musím psát ručně, protože je to lepší, než je tvořit vizuálně.
U komplikovanějšího UI se to pak docela blbě udržuje. Dělat změny UI ve stovky řádek velkém XML zdrojáku není nic pohodlného.
Robiť UI v textovom jazyku je dnes už de facto štandard, viď XAML alebo aj HTML. Robiť zmeny v takom UI nie je nič, čo by malo niekoho od toho odradiť. Ja si naopak neviem predstaviť robiť takéto veci vizuálne, kde sa musím myškou triafať na presné miesto, ale asi to je vec zvyku.
Každopádne, začiatočníkovi by som určite neodporúčal, aby začínal tvorením multiplatformných GUI aplikácií.
Počkej, ty mluvíš o HTML stránce, kde je GUI poměrně jednoduché - žádné složité vrstvení komponent na sebe, dockování atd.
Ony ani ty mobilní aplikace nemají složité UI, protože tam často řešíš různé formáty displeje a potřebuješ, aby se ti tam vše vešlo.
Když si vezmu zdroj definice složitějšího formuláře, tak se dostávám na tisíce řádků - a to je jen opravdu rozložení komponent a nastavení jejich vlastností bez vlastního kódu. Tohle si zase já nedovedu představit - vrátit se 15 let zpět zpět a psát to všechno ručně.
Ale to bude tím, že každý z nás dělá jiný typ aplikací.
Tisíc riadkov len na rozloženie komponentov? To by muselo byť niečo veľmi zle, aby niekto taký formulár napísal. Textový formát má oproti vizuálnemu svoje výhody, ale to už je mimo túto diskusiu.
Proč myslíš "velmi zlé"?
Někdy je výhodnější mít na formuláři page control, uživatel si přepíná pohledy a dotahují se mu data k dokladu než pro každý pohled otevírat nový formulář (v HTML novou stránku) a pak to zase zavírat a vracet se. Šlo by to řešit 20 malými formuláři a 20 tlačítky, které je budou volat, ale na úkor uživatelského komfortu.
Já samozřejmě můžu pracovat v textové formě, pokud potřebuju něco hromadně změnit na všech, tak klidně přes hledat/nahradit, ale mám i možnost to dělat vizuálně. Když dostaneš formulář, který jsi nedělal a chceš najít událost nějakého prvku, tak to určitě budu mít nalezené dřív.
Je to tím, že každý děláme odlišný typ aplikací.
V ERP potřebuje uživatel rychle pořídit doklad, často i bez koukání na obrazovku, nemůže pro každou kravinu klikat na tlačítka, otevírat a zavírat nové a nové formuláře a čekat na ně. Na webu s tím počítáš - klikneš a víš, že může trvat, než se načte další stránka, počítáš s tím, že na všechno potřebuješ myš. Na mobilu zase klikáš prstem, kam potřebuješ. To se vše přenáší v poslední době na desktop, takže roste generace klikačů, kteří místo stisknutí Enter chytnou myš a kliknou na tlačítko.
Pretože toto všetko vieš rozdeliť na menšie komponenty. To, že je niečo samostatný komponent, neznamená, že sa to musí otvárať v novom okne. Z pohľadu toho, čo vieš dosiahnuť jedným alebo druhým spôsobom, sú obidva spôsoby ekvivalentné - určite tam nie je nič na úkor používateľského komfortu.
V čom je ale podstatný rozdiel, je vygenerovaný kód pri vizuálnom editovaní. Z vygenerovaného kódu netušíš, ako formulár vyzerá, takže vizuálny editor je nutnosť, nie pomôcka. Identifikátory vygenerovaných prvkov sú nič nehovoriace textbox1, textbox2, a tak ďalej. Udalosti sú potom neraz pomenované ako button1_Click, button2_Click, a tak ďalej - to prehľadnosti neprispieva. Ak tam máš nebodaj vnorené panely s takými názvami že panel1, panel2, panel3, tak veľa zábavy pri vizuálnom editovaní, ale tej si užiješ aj pri normálnejšie pomenovaných paneloch. Alebo ďalšia vec, už len tým, že pridáš nové tlačidlo doprostred nejakého formulára, úplne rozbiješ navigáciu pomocou Tab klávesy a musíš to znova ponastavovať, ak si vôbec všimneš, že si niečo rozbil. A na záver úplná čerešnička, stráviš kopec času upravovaním formulára a zrazu zistíš, že kolega medzitým posunul niektoré prvky o pár pixelov vedľa, takže môžeš robiť všetko znova, lebo merge z toho spravíš ťažko.
Možno sa niektoré veci z toho, čo som napísal, za posledných 15 rokov zmenili, ale veľmi silno pochybujem, pretože to nemá normálne riešenie. Rád sa ale nechám vyviesť z omylu.
To, že to někdo nechá pojmenované vygenerovanými jmény je stejná čuňárna, jako bys to takto psal ručně v návrhu. Ty to neuděláš a já taky ne.
Pokud ty jsi schopný z napsaného kódu vidět, jak formulář vypadá, tak já taky - potřebuješ na to hodně představivosti. Já to řešit nepotřebuju, protože se mezi popisem a vizuální formou jednoduše přepnu.
Rozdělit to na menší komponenty myslíš, že třeba oddělíš panel a prvky na něm do zvláštního souboru? To pak máš formulář, který se skládá z 20 souborů a pokud se chceš dopracovat ke změně nějakého prvku, pak musíš prolézt několik souborů. V tom nevidím velkou výhodu. Já tohle můžu udělat taky. Máme své komponenty/bloky komponent včetně funkčnosti, které jen položíš na formulář a máš zajištěnu kompletní funkčnost (vizuální stránku, zapouzdření objektem, kód, práci s DB). Tohle ale nemá smysl dělat se vším jen proto, abych neměl velký soubor s popisem formuláře, ale v případě, kdy chci mít funkční blok, který upravuji a udržuji na jednom místě.
A ano, za 15 let se toho hodně změnilo. Pokud jsi se pohyboval v MS světě, tak tam první pořádné IDE a vizuální návrh formulářů dělali lidi od Borlandu, které MS přetáhnul.
Nechme to, až se uvidíme, pak si to můžeme ukázat na nějakém příkladu v reálu a můžeme se rovnou pohádat
Ja viem, že vygenerované názvy sa majú vždy nastaviť, ale k tomu ťa ten vizuálny editor nevedie, je to jeho vlastnosť a zároveň chyba. Každý, kto s vizuálnym editorom začne, sa k disciplíne s pomenovaním dopracuje až postupne (niekto nikdy), takže to považujem za problém vizuálneho editovania, ktorý v textovom formáte jednoducho neexistuje. Čo sa týka textového formátu, tak predstavivosť nie je ani potrebná, vizuálny náhľad sa dokáže zobrazovať počas písania.
Delenie na komponenty je základný princíp každého dobrého GUI frameworku, takže neverím, že v tom nevidíš veľkú výhodu, ale to je jedno, lebo toto majú spoločné obidva prístupy. Ale zaujímalo by ma, ktorá z tých zopár základných problémových vecí sa za tých 15 rokov zmenila k lepšiemu, asi žiadna. A to som ani nezašiel do väčších problémov, ktoré nastanú vtedy, keď si chceš vyrobiť nejaký trochu serióznejší komponent sám.
Asi to nebude takhle přímočarý; nešel jsem nijak do hloubky, ale zdá se, že je potřeba tandem C Sharp a .NET.
Nějaký info je např. tady: Vývoj mobilních aplikací pro různé platformy v aplikaci Visual Studio
Priamočiare to nie je ani v Delphi. Keby to bolo také jednoduché, tak už dávno by bol Total Commander dostupný na Linuxe a MacOS.
Neviem prečo ťa všetci odhovárajú - máš jasnú predstavu, rieši to reálny problém, získaš skúsenosť s programovaním, máš potenciálne platiacich zákazníkov. Podľa mňa ideálne podmienky. Ak je cieľom len zarobiť na aplikácii, tak to asi nie je najlepší spôsob, ale stále sú tam ďalšie pozitíva.
Čo sa týka existujúcich aplikácií - aj keby existovali, integrácia s existujúcou databázou bude aj tak individuálna, takže existujúce aplikácie sú irelevantné. Veľa spoločností napr. poskytuje zákazníkom aplikáciu na zobrazovanie faktúr, t.j. aplikácie na zobrazovanie faktúr existujú. To neznamená, že keby som mal spoločnosť, ktorá potrebuje zákazníkom zobraziť faktury, že nejaké existujúce riešenie by bolo aplikovateľné bez úpravy.
To, či by mohlo problém vyriešiť použitie násobilky namiesto aplikácie, je úplne od veci argumentácia. Pokladníčka tiež nerieši pri každej platbe, koľko má vydať späť zákazníkovi - skrátka sa jej zobrazí číslo a podľa toho ide. Alebo keď mám niekde zadať číslo (číslo karty, čísla zo šeku, číslo z elektromera), tak ani násobilku nepotrebujem a môžem číslo ručne odpísať. To ale neznamená, že aplikácia, ktorá dané číslo naskenuje, je zbytočná. Znamená to len toľko, že ľudia, ktorým stačí násobilka alebo manuálne odpísanie, to spravia za dlhší čas a/alebo chybne.
K jazyku, C# zvládne tvoje požiadavky. Je to samozrejme multiplatformný jazyk, môžeš v ňom spraviť aj mobilné aplikácie. Za zváženie možno stojí JavaScript/TypeScript (mohlo by to bežať napr. v prehliadači, prípadne v Electrone), prípadne Python, alebo Java/Kotlin, alebo TIScript. Ale ten C# mi znie pre teba ako najjednoduchšia možnosť. Každá možnosť má svoje výhody/nevýhody - závisí, či chceš jeden kód pre všetky frontendy (desktopy/mobily/web), alebo chceš optimálnu/natívnu aplikáciu pre dané prostredie.
Rozumiem pocitu, že zverejnením problému by si stratil akúsi výhodu na trhu, ale nemyslím, že je na mieste. A to hlavne kvôli tomu, čo som písal vyššie o existujúcich aplikáciách.
Pod toto sa môžem podpísať. Úplne ideálne podmienky pre tvorbu softvéru: jasná predstava o požadovanej funkcionalite, rieši reálny problém, a ešte k tomu aj potenciálne platiaci zákazníci. Nemá zmysel hľadať "niečo menšie na učenie sa", toto je úplne najlepší spôsob.
Ideální je začít s něčím, co jsi schopen (třeba s mírnou dopomocí) dokončit sám.
Dokončit sám finální produkt, který je funkční, dobře otestovaný, nepadá, nezasekává se, nedělá chyby v okrajových případech, má funkční UI, je konkurence schopný, bude se prodávat a používat v reálném prostředí, bude mít support, dokumentaci (online?) atd. je pro jednoho člověka obrovská výzva i když má zkušenosti.
To není jen o výběru jazyka ve kterém napsat ten výpočet, pokud možno multiplatformně.
- Dokumentaci v pdf? Musíte umět vytvořit to pdf. Nebo dneska spíš online ne? Tak při nejmenším aspoň HTML a CSS případně ještě JS / PHP (a to na nezanedbatelné úrovni).
- Naprogramovat to v samotném jazyku bez knihoven? to těžko, na výpočet bude nejspíš potřeba nějaká matematická knihovna, na grafické klikátko další, na 2d zobrazení další, na 3d další, bude pak potřeba použít nějakou na vícevláknové/asynchroní operace aby byl software responzivní? to je 5 knihoven o kterých víme už teď a každou trvá nějakou dobu se naučit.
- Velký projekt pro zákazníky bez verzování? tak to určitě fungovat nebude, takže se ještě musí naučit Git a jak ho používat správně, to je zase něco co je samo o sobě dost složité. (YouTube s videem "Git in 15 minutes", může pomoci ale jen praxí v tom člověk získá jistotu)
- Co UX? to je samostatný obor co nemá s programováním nic společného, a soft pro reálné nasazení musí mít dobré UX, jinak ho nikdo používat nebude.
- Učil se tazatel na střední škole OOP? Né že by to bylo nemožné, ale spíš ne, ale pokud je to komplexní soft potřebovat ho bude.
- Co testy? Napsat dobrý jednotkový test taky není jen tak.
- Co debuging, profiling, ...
- Best praxis, code style, integrační testy, testy uživatelského rozhraní, tohle není nutné, ale hledejte pak chybu když soft je v produkčním prostředí a je potřeba něco rychle opravit, bez dobrých návyků jak psát dobrý software to bude noční můra.
Tohle rozhodně není ideální úloha pro někoho, kdo měl jeden rok na střední hodinu programování týdně se špatným učitelem a chce si to "oživit", (což v podstatě znamená všechno se znova naučit, protože za 2 roky je v programování všechno jinak).
Tazateli bych spíš doporučil ať si najde seniorního vývojáře, u kterého by byl na stáži nebo tak něco.
S týmto príspevkom nesúhlasím asi v každom jednom bode.
Produkt môže byť nedokončený, nedoladený, padať každú hodinu, zasekávať sa, robiť chyby pre krajné prípady, mať polofunkčné UI, byť bez dokumentácie a dokonca aj bez supportu, a napriek tomu môže byť úspešný, predávať sa a používať sa v reálnom prostredí. Videl som taký produkt naživo. A nie je na tom nič nelogické. Pre človeka, ktorý ho používa, je podstatné, či produkt plní svoj účel - či šetrí čas, peniaze, úsilie, a podobne.
Ďalšia vec je, že cieľom je sa aj niečo naučiť. Neexistuje lepšia príležitosť naučiť sa programovať, než riešiť niečo, čo chceš reálne vyriešiť. Vtedy môže byť učenie zároveň aj zábavou. A že to nebude dokonalé po všetkých stránkach? O to predsa ani nejde.