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.
To už nedokážu posoudit, dělám hlavně BE pro webové aplikace. Když už potřebuju něco desktopového, tak je většinou nějaká malá blbost. Ale spíš předpokládám, že tam funguje nějaký rozpad na menší komponenty se samostatným kódem.
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
To je skoro, jako bys řekl, že je potřeba tandem Java a JVM. Ty věci jsou k sobě tak blízko, že se v praxi často zaměňují, byť jedno je jazyk a to druhé framework.
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.
Frameworku, ktere se chvastaji, ze tohle umi je asi milion. Ale z praxe vim, ze stejne nakonec jsou dva teamy, ktere pisi stejnou appku v Swift/Objective-C pro iOS a pro Android v Java/Kotlin. Protoze to je proste lepsi...
Kdyby tu byl někdo, kdo by mi pak dokázal pomoct s tím výstupem - jak palety naskládat, aby se to tam vešlo. Ozvěte se mi prosím, rád bych to s někým prokonzultoval a toto asi nezvládnu, samozřejmě na ceně a všem ostatním se rád domluvím. Díky! :) Snad toto není proti pravidlům fóra (Když tak se omlouvám).
Mrkni se na lineární programování, simplexovou metodu.
Teď bych už to nezvládl, zkoušku z toho jsem dělal někdy kolem roku 1980…
Fandím ti a oceňuju, že se chceš něco naučit a máš svůj vytyčený cíl.
Jenom jak tu zaznělo, možná bys měl začít něčím menším a důkladně si zmapovat situaci na trhu. Vytvořit profi program není zrovna snadné, pro tebe by bylo možná lepším řešením svoje know-how prodat nějaké firmě nebo si to nechat naprogramovat od někoho, kdo s tím má zkušenosti.
V minulosti se tady objevilo několik nadšenců, kteří chtěli začít programovat hry typu Counter Strike a přitom neuměli ani vytvořit Hello World. Jak jejich plány dopadly, se už nikdy nikdo nedozvěděl....
Díky za názor
Samozřejmě si nejdřív zkusím nějaké basic příklady, jako třeba Hello World. Ale věřím, že když něco v C# opráším, tak se mi vybaví nějaké zkušenosti ze střední. Každopádně aspoň to zkusím, případně jak říkáš, zkusím najít někoho zkušeného a udělat to přes něj :)
A chápeš taky, že když máš problém algoritmicky zpracovanej, že přepsat ho do formy programu už není (obvykle) nic složitýho?
Jenže ty nemáš to nejdůležitější, to podstatný a to je algoritmus, kterej vyřeší problém s nakládáním zásilek.
Ano nemám ani to, já nad tím totiž jen zatím přemýšlel, samozřejmě si nejdřív vezmu papír a pořádně to promyslím, než to budu přepisovat. Nejde tu ani o nakládání zásilek.. Původně jsem dotaz napsal jen kvůli dotazu na programovací jazyk, samozřejmě že po Vás nechci rady jak to udělat, když Vám ani neřeknu, o co přesně jde. Tudíž půlka odpovědí je zde nemístných, protože ve finále to vůbec o paletách není. Každopádně jsem ale moc rád za každou odpověď tady a že si s Váma o tom můžu pokecat. Ale nejvíc mi k tomu asi potom řekne programátor, který ví o co jde.
Nepotřebuješ programátora, ale analytika. Je pravda, že se často vyskytuje pozice "analytik - programátor", ale není to pravidlem. Je-li precizně provedena analýza a návrh programu, programátor nemusí o dané problematice skoro vůbec nic vědět.
Tvé zadání vyřešit nelze, ale když to nebudeš respektovat, tak se Ti to možná i povede!
Ale samozřejmě že to lze vyřešit, vše nějak půjde vyřešit. Nemůžeš mi přece říct, že to nelze vyřešit, když jsem tu ani nenapsal, o co vlastně půjde :D Až mi toto řekne nějaký seniorní programátor, který bude vědět detaily a o co vlastně jde, tak to teprve vezmu vážně
To bylo myšleno jako parafráze známého výroku: "Nevěděl, že to nejde, tak to udělal."
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.
Já se mu snažil říct, že umět napsat program nestačí; potřebuje ten problém nejdřív vyřešit algoritmicky. I další mu tady dávali smysluplný rady.
Nevím, kolik jsi toho z tohoto vlákna četl. On má zatím minimální znalosti a hlavně zkušenosti s programováním.
Jak daleko statisticky takovej člověk dotáhne větší projekt?
Vlákno som čítal celé. Nehovorím, že rady neboli zmysluplné, len boli často zbytočne pesimistické (nebudem citovať konkrétne). Má minimálne skúsenosti s programovaním, má potenciálne užitočný projekt na ktorom sa to programovanie môže naučiť - tak to je predsa dobre, nie? Má sa učiť spraviť programovať niečo, čo nemá využitie? Či projekt dotiahne do konca alebo nie, to záleží na ňom, každopádne získa tie skúsenosti s programovaním.
A tobě nepřijde logický, začít prvně s něčím menším? Jak ses učil programovat ty? Učil ses prvně něco o algoritmech, datových typech, programových strukturách, globálních a lokálních proměnných, volání funkcí, předávání parametrů, atd.?
Nebo ses rovnou vrhl na programování "a teď si něco napíšu"?
V každým oboru se začíná od začátku a od základů, ať je to kuchař, instalatér, řezník, cukrář, elektrikář nebo programátor.
Základom je rozdeliť problém na menšie časti a tie riešiť postupne. Takže po tom rozdelení samozrejme začne s menšou časťou. Samozrejme nezačne písaním inštalátora, ale od nejakého normálneho začiatku. Algoritmus predpokladám v hlave má, len ho nevie zapísať do spustiteľnej aplikácie.
Možná jo, možná ne, to bysme hádali.
Podle mě jseš moc velkej optimista v tom, že i když nemá znalosti a zkušenosti, rozdělí si projekt na menší části a díky tomu to vlastně zvládne.
Za mě má palec nahoru za snahu. Já jsem si naprogramoval svou vlastní hru "textovku" pro Didaktik, když mně bylo 12, dneska už bych to nedal, protože si basic nepamatuju a živím se něčím jiným, než jsou PC. Alespoň je vidět snaha, toho si cením nejvíc a snad se mu to podaří.
Vrhnul jsem se na programovani stylem "a ted si neco napisu" a "do tyhle gamesy si pridam zivoty a naboje" a teprve pozdeji jsem se zacal ucit o algoritmech a dalsich odbornostech.
A kdyz jsem presel od programu tak na 10 radek k delsim, tak do roka jsem mel napsany vlastni prekladac, zcela jiny interaktivni interpreter s "grafikou" a textovku s vlastnim enginem. (a kazde to melo prez 1.000 radku a fungovalo to spravne)
Verzovaci systemy jsem potkal az par let potom.
Kdo mu tu co rozmlouvá? Jenom ho upozorňujeme na možné problémy. Je dobré si je uvědomit předem.
A já jsem za ty upozornění rád, díky :)
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.
Přesně tak :) Díky :)
Díky!! :) Samozřejmě žádný z komentářů zde neberu jako špatný, ač je 90% komentářů spíš pesimistických. Ale zase je to pravda a já si díky tomu uvědomím, co všechno bude potřeba se naučit a že to nebude vůbec lehké. Ze zkušeností v minulosti vím, že učení se programování na něčem, co nemá cíl a ani tolik smysl, tak ne akorát odradí a né úplně mne to bude bavit. Proto jsem si řekl, že než abych sháněl nějakého seniora, který by to vytvořil (což už by mne stálo nějaký kapitál) tak se na tom zkusím programovat, ač už mi to bude trvat delší dobu. Každopádně myslím, že k tomu programování nemám zase tak daleko a dokážu se v tom rychle orientovat. A ten pocit, když vytvořím něco, co bude fungovat, je k nezaplacení.
Na mě to dělá dojem, že chce vytvořit něco jako "nářezový plán".
V mé situaci je to úplně něco jiného.. Ale chápu, že Vám to při mém popisu na falešném příkladu takto připadá.
Taky jsem to tak pochopil, proto ten simplex :)
Akorát v 3D.
Před 40 lety mě to hodně bavilo, tohle počítat... případně úloha obchodního cestujícího apod.
Díky všem za normální odpovědi a rady :) Pokud máte tip na super studijní materiály na C# basics, tak budu rád za sdílení