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 :)
Že by vážně taková aplikace neexistovala? Klidně bych se vsadil, že logistické firmy něco takového mají. Pokud to bude desktopová aplikace pro Windows, tak klidně použij C#.
Oukej, já doufal v C#. Takže tedy C# a Visual studio. Toto byl jen příklad.. Ve skutečnosti bude aplikace fungovat na takový způsob, ale né na palety. Mám kontakty na hodně lidí z odvětví na které bude appka mířit a všichni si stěžují, že nic takového ještě není a že si za to klidně zaplatí.
Tak si taky zjisti, kolik takových lidí je a kolik by za to byli ochotni zaplatit. Abys pak nezjistil, že tvoji půlroční práci by dohromady ohodnotili na 50 000 Kč.
Jasný, vše si teprve zjistím. Ale mohlo by to mířit na velké firmy. Každopádně o tom ještě brzo mluvit, musím to pořádně vymyslet. Díky za řešení
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...
Díky za radu! Ten mobil je spíš výhled do budoucna, pokud se appka na desktopu chytne. Ani si nemyslím, že by to bylo něco těžkého. Dva vstupy, vytáhnou data z databáze a pošlou výstup ano-ne.. Ovšem je potřeba pak zakomponovat nějak to, aby to ukázalo, jak poskládat tak, aby se to tam vešlo. To už asi tak jednoduché nebude.
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?
Xamarin.Forms is an open source mobile UI framework from Microsoft for building iOS, Android, & Windows apps with .NET from a single shared codebase.
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.
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...
V jakém jazyce pak budu schopný napsat ten program ?
Když nevíme, co ten program má dělat, logicky ani nelze doporučit programovací jazyk.
Jasný, chápu, má chyba. Příklad na nějak tak stejný způsob jsem napsal do komentáře nad tímto. Díky :)
Na dotaz tak jak je položený existuje odpověď: Jdi tam nevím kam přines to nevím co. Napadá mne, kdysi se mluvilo o nějakém nástroji Soukup Graphic Preprocessor. Nebylo to něco podobného co chceš řešit ty?
Chápu :) Měl jsem to napsat, má chyba. Napsal jsem příklad v komentáři nad tímto :) Díkyy (y)
Chápu - to je skutečně něco jiného. Po přečtení dotazu jsem měl dojem, že chceš napsat něco co usnadní psát program, případně to bude průběžně kontrolovat. Když se do toho chceš pustit, nenech se odradit, kdo ví, kdy se ti to co se při tom naučíš může v budoucnu hodit.
V podstatě skoro každý programovací jazyk by to měl zvládnout, některé jsou jednodušší, jiné složitější. (teda chápu, že napsat v Brainfuck-u program, co ti to přez G-code vykreslí na CNC asi není ideální cesta, ale taky by to asi šlo obecně bych se vyhnul této kategorii https://en.wikipedia.org/wiki/Category:Esoteric_programming_languages )
Pokud to C# jakobys neměl, uvažoval bych spíš třeba o Pythonu, který spoustu věcí umožňuje dělat jednodušeji, je populární a je k němu spousta knihoven (i na generování obrázků třeba). Je asi o něco pomalejší, než C#, ale na tohle by to vadit nemělo, zato se v něm píše rychleji a snáz se ladí = kratší vývoj takovýchto jednodušších programů.
Díky! Mrknu podrobně na porovnání Pythonu a C#
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…
Prvně to vyřeš algoritmicky, pak můžeš uvažovat nad jazykem, do kterýho to přepíšeš.
Jseš si jist, že to opravdu zvládneš? Nevzal sis moc velký sousto?
Vzal jsem si velké sousto. Počítám s tím, že to bude trvat dlouho. Ale jsem rád, že mám cíl a můžu se to na tom učit. Zároveň si myslím, že by program mohl mít budoucnost. Při nejhorším si budu muset sehnat seniora, který mi s tím pomůže.
A nebylo by lepší udělat prvně pár menších projektů?
Ta tvoje optimalizace - řešící problém co chceš programovat - bude 2D nebo 3D? Pokud s tím nemáš předchozí zkušenosti, bude to náročný.
Ten poslední výstup poskládání, bych rád dal do 3D grafického zobrazení. Nějakého basic.. Ale to už sám určitě neudělám, celkově tenhle výstup o možnostech poskládání asi vůbec sám nezvládnu.
Bude těch variant, jak to tam naskládat hodně? Pokud by jich bylo jen pár, možná by ten problém šel obejít tak, že by se to "natvrdo" uložilo a pak by se jen vybralo zvolený řešení.
Ale pokud těch variant budou třeba stovky, pak budeš potřebovat pořádně studovat. Sám bych nevěděl, jak na to.
P.
Těžko se o tom mluví, když tu veřejně nechci vysvětlit podstatu problému. Ale variant bude dost.. Každý kontejner bude různě velký a palety též různě velké, tudíž variant asi bude dost :/
Tak v prvnim kroku udelat databazi palet a kontejneru a hledat v ni je celkem snadny krok.
pak pridat test na vahu je taky easy
pridat "silne orientacni" test, zda soucet objemu palet neni vetsi je taky snadne - pokud je, tak se to sichr nevejde
a pokud se tam daji naskladat trivialne (vyzkouset par zakladnich variant - podelit delky a zaokrouhlit dolu na cela cisla ), tak je to fajn a sichr se to vejde
a pokud by se objemem vesly a trivialne ne, tak muze zkusit neco pokrocilejsiho, jako treba kombinace dve rovne, jednu nastorc a tak ... to uz je pokrocilejsi a pripadne tam mrsknout i neco s 3D skladanim a generickymi algoritmy pro rozhodnuti tech veci mezi tim, pokud si bude hodne troufat
A zobrazovani taky muze udelat po nekolika ruzne slozitych krocich.
Přesně tak.. Samozřejmě tu nejde opravdu o kontejnery a palety ( Přesný účel programu tu nechci popisovat, to jistě chápete) Ale "kontejnerů" bude opravdu jen 6, tudíž vypsat databázi nebude těžké.. Palet už samozřejmě může být opravdu dost, tudíž nevím, zda to vypíšu ručně, nebo to zkusím přepojit přes nějakou databázi na internetu. Lehčí, ale delší bude to vypsat. Takže toto nevidím jako tu těžší část. Ale poslední výstup se srovnáním palet tak, aby se to vešlo, nebude jednoduché a sám to asi nezvládnu.
Taky pozor na to, zda krabice/palety můžou být v libovolných polohách. A pak ještě pozor na to, když rozměry vyjdou natěsno, např. tři krabice vedle sebe -> 110 cm a vnitřní rozměr kontejneru -> 111 cm; zdánlivě to stačí, ale když se tam ty krabice budou dávat, už nezbude dost prostoru na ruce.
Ve skutečném případě nebude ani jedna tato možnost hrozbou, "paleta" bude moct být jen v jedné poloze a nebude se zde pokládat ručně, takže jí lze dát na těsno. Omlouvám se, že ve skutečnosti neřeknu o co jde, ale je to podle mě dobrý nápad a knowhow, kterého by někdo mohl zneužít, kdybych ho tu veřejně napsal. Tudíž tyto věci asi spíš pak budu řešit s nějakým specialistou, se kterým se o nápad podělím a budu po něm chtít pomoct s tímto konečným "poskládáním"
Nedokážu identifikovat, zda v tom segmentu, kde se pohybuješ něco takovýho už neexistuje. Ale obecně, nějaká optimalizace 3D rozmístění krabic v kontejneru musí existovat už drahný léta; to využívá (nejen!) letecká a lodní doprava.
Jasný, ohledně krabic v kontejneru vůbec nevím, to asi něco opravdu existuje. Já to ale použil jen jako příklad, ve skutečnosti jde o úplně něco jiného. V tom mém segmentu tento program opravdu chybí, mám známého, co v tomto segmentu má firmu a samozřejmě i kontakty na vztahy s ostatníma v tomto segmentu. A prý si všichni říkají, proč toto ještě nikdo nevytvořil, že by jim to strašně ulehčilo práci. Ovšem stěžují si na to "zaměstnanci" mezi sebou a nepošlou to mezi management, tudíž se to stálo ještě nevytvořilo.
A management na to: proč jste to neřekli dřív? Ten program už existuje a stačí ho koupit
Toto už mám zjištěné.. na 100% takový program neexistuje. Je možné, že ho někdo vyvíjí na přání společnosti, ale to si nemyslím. Ale já se na tom rád neučím něco málo z programování a uvidím konečně taky něco jiného než SAP a SAPí integrace. Takže na tom ztratím akorát svůj čas, který bude zároveň jako studium programovacího jazyka a když to dobře dopadne, bude dobře placený.
To by ses divil, kolik existuje různých softwarových produktů, o kterých nemáš ani tušení.
Nepřijde mi to moc pravděpodobný.
Kdybys kápnul na nějakou novinku; pak chápu, že ještě nemusí existovat optimální způsob a dá se přijít s novým řešením. Ale v případě "krabice do kontejneru" to prostě na nový, dosud neexistující řešení fakt nevypadá.
Opravdu to tak je, mám v tomto odvětví mnoho názorů od lidí, kteří by to využili, ale nevědí o ničem takové, že by to existovalo. Dělají to způsobem, že to prostě nějak poskládají. Ale se ztrátou času a nervama.
Tudíž tyto věci asi spíš pak budu řešit s nějakým specialistou, se kterým se o nápad podělím a budu po něm chtít pomoct s tímto konečným "poskládáním"
To je právě ta podstata, to ostatní kolem je víceméně bižuterie. Takže nepůjde o pomoc, ale o vyřešení problému.
To já jen tak, aby to bylo jasný.
Palet už samozřejmě může být opravdu dost, tudíž nevím, zda to vypíšu ručně, nebo to zkusím přepojit přes nějakou databázi na internetu. Lehčí, ale delší bude to vypsat.
¨
Tohle se dělá tak, že si program stáhne aktualizaci z internetu a pak si to drží u sebe v lokální databázi. Ty jen provedeš aktualizaci na netu - přidáš položky, na nějaké místo dáš informaci, že došlo k aktualizaci a program bude vědět, že si má stáhnout nový seznam.
Ale poslední výstup se srovnáním palet tak, aby se to vešlo, nebude jednoduché a sám to asi nezvládnu
Jde o to, zda mohou být bedny a palety v kontejneru libovolně, nebo zda tam musí být naskládány s ohledem na logistiku - třeba pro jednoho zákazníka pohromadě nebo se dodržuje pořadí podle zákazníků. Abys pak nedojel k prvnímu zákazníkovi a nezjistil, že musíš kontejner celý vyskládat, aby ses dostal k paletě, která je úplně v zadu.
Po těchto konverzacích se toho ještě víc bojím.. No bude to běh na dlouhou trať a výzva, tak snad se s tím nějak poperu. Každopádně díky všem za rady. Když občas čtu ty poradny, kde hned padají odpovědi typu - najdi si to na google, když o tom nic nevíš, tak do toho nelez apod. Tak jsem se toho trochu bál. Sice mám nějaký ten "opravdu mini" základ v pár příkazech, ale zase třeba vůbec netuším, jak se řeší grafické zobrazí toho programu. Aby to neběželo někde v příkazové řádku. Takže to opravdu nebude lehkéé
A taky nezapomínej, že vytvořením programu to zdaleka nekončí. Prodáš to firmám a ty určitě budou chtít mít podporu. Co budeš dělat, když ji třeba budou požadovat 24/7 a vyřešení problému do 2 pracovních dnů? Co když budou chtít mít k tomu dokumentaci? Máš někoho, kdo ti ji napíše a třeba i přeloží do angličtiny?
Toto bych asi řešil v případě, že tu aplikaci už budu mít. Nejdřív vypustit nějakou testovací verzi a až to bude vychytané, tak pak nabízet roční licence. Ale děkuji za postřeh, určitě toto pak bude potřeba řešit. Ale myslím, že až se dostanu do bodu, kdy toto budu řešit, tak už program nebudu vyvíjet sám, tak ohledně toho budu mít snad i nějakou pomoc, která už třeba nějaký program někdy vypustila.
Takže vlastně chceš vyřešit tzv. Bin Packing Problem - tož hodně štěstí! Ani ne tak s programováním, ale především s návrhem algoritmu!
K nejznámějším paletizačním SW patří palOPTI, TOPS Pro, Cape Systems (ten pracuje i jako plug in v rámci konstrukčního SW ArtiosCAD). Zde SW na základě daných vstupních parametrů zoptimalizuje varianty skupinového i spotřebního balení. Následuje optimalizace rozmístění krabic na paletě (SW obsahují velké knihovny různých nadefinovaných typů) a pozdější rozmístění paletových jednotek na další ložné ploše – automobil, sklady apod. Se všemi těmito SW se snadno pracuje, neboť v jednotlivých krocích nechybí barevné prostorové náhledy, které přispívají k uživatelsky přátelskému prostředí jednotlivých produktů.
Jak už jsem říkal, příklad kde uvádím palety a kontejner je jen příklad. Ve skutečnosti se nejedná o palety a ani o kontejner. Tudíž je to úplně mimo tento SW.. Chápu že to bude opravdu těžké.. Možná by bylo jednodušší, kdybych se o nápad podělil s nějakým senior programátorem, kterému by se to zalíbilo a šel by do toho se mnou
Potřebuješ především odborníka (či spíše odborníky) na algoritmizaci problému s matematickým VŠ vzděláním. To, co chceš naprogramovat (aspoň tak jak jsi to popsal) je totiž obecně velmi složitý problém (tzv. NP těžký problém), který lze řešit jen heuristickým algoritmem. Do téže množiny patří např. úloha obchodního cestujícího. Na týhle úrovni problémů si bez znalosti matematiky z VŠ vzdělaní ani neškrtneš.
Pokud bych ale chtěl jen program, do kterého zadám ty dvě vstupní hodnoty, ono si to vytáhne z databáze rozměry a řekne mi, zda se množství palet do kontejneru vejde (ANO-NE) tak to tak moc složité není, že ?
No, budeš se asi divit, ale složitost bude v podstatě stejná. Příklad (po jednoduchost ve 2D): * máš čtyři palety 2,5 x 3 m, plocha palet je 4 * (2,5 * 3) = 30 m2. * máš kontejner 4 x 9 m, plocha kontejneru je 4 * 9 = 36 m2. Plocha palet je o dost menší, než plocha kontejneru (konkrétně zde 83,3 %), přesto ty palety do kontejneru nenaložíš. Těžko to zjistíš bez toho, že by ses v tom SW pokusil ty palety poskládat. A teď to ještě budeš mít ve 3D s různou velikostí palet...
V mém případě to ale nebude ve 3D.. Změním tedy příklad, aby to bylo více pochopitelné.. Máte Nákladní automobil, který má jako návěs dvě plochy za sebou, čisté plochy (obdelníkové - čiže jako normální návěs, ale bez plachty. Tudíž je tu jen podlaha a kola. A na ty dvě plošiny naložíte vždy cca 6-8 krychlí. Každá krychle se totiž liší jen o několik desítek centimetrů, z toho důvodu jich tam vždy bude 6-8. Tudíž zde nezáleží na výšce a objemu krychle. Spíš pouze na šířce a délce.
Vlastně ani né tolik na šířce.. Jelikož krychle budou za sebou.. Nikdy né vedle sebe.. A každá krychle je stavěna tak, aby tolik nepřečnívala z návěsu.. Takže nám vlastně jde jen o délku.
Takto popísaný problém vyzerá byť veľmi easy...Na to Ti stačí v ruke kalkulačka a nepotrebuješ špecializovaný sw...
Ať teda vedení firmy koupí zaměstnancům kalkulačky, to vyjde levněji než software.
Na takto popsaný problém opravdu nepotřebuješ speciální SW, na to stačí malá násobilka. Asi někdo z nás (nebo oba dva) něco nechápe...
Nechci tu psát přesnou podstatu programu, proto Vám to přijde blbé a zbytečné. Ono to ve finále není tak jednoduché. Každopádně chápu Vás, že to nechápete.
A co je cílem té optimalizace? Naložit co nejvíc kusů? Nebo naložit náklad tak, aby se v definovaným pořadí (např. pro zákazníky A, B C) vyskládal? Je jedno, zda se bedna uloží na přední nebo zadní návěs?
Když mi dodavatel řekne, že mám naložit tohle a tohle, tak abych to zadal do appky a mohl mu říct, to se vejde a to se nevejde. V těžší fázi by mi to řeklo.. Ano, to se vejde, ale naskládej to takhle. A také do toho zahrnout kdy a co se kde bude vykládat (přesně jak jste psal, něco se vyloží dřív, proto to dám dopředu. Ta konečná fáze toho třídění bude těžká a bude na to potřebný nějaký IT matematický expert, v tom máte pravdu :/
Na tu poslední fázi budeš hlavně potřebovat naprogramovat trasu - zákazníky poskládat tak, abys měl co nejkratší trasu a současně vyhověl jejich otevíracím hodinám (případně oknu, kdy je schopný to zákazník přebrat).
To už není potřeba, to už se řeší zákazník sám a jinak.. V tomto případě zjednodušeně řešeno.. Budu zadávat palety od první k poslední podle toho, kterou vyložím jako první a jako poslední. To se zohlední při tom, jak program určí každé paletě místo.
Takže znovu sa dostávame okľukou k "paletizácii", resp. logistike nakladania a vykladania "niečoho"....
Mám pocit, že chceš vymyslieť niečo, čo tu už dávno existuje (možno v mierne inej podobe)....
Tohle se mi zdá už minimálně třetí varianta toho, co se má vlastně řešit; myslím tím, že je to minimálně třetí popis zadání.
Zdá se mi, že prostě stačí naložit ty palety v opačným pořadí, než se budou z návěsy vykládat. A jestli se tam na návěs vejdou všechny, to se ověří lehce tím, že se sečtou jejich rozměry + (případný) mezery a porovná se to s délkou návěsu.
Možná je to překlep možná to myslíš jinak, možná to špatně chápu, ale:
něco se vyloží dřív, proto to dám dopředu
Čekal bych, že to co se vyloží dřív se dá na návěs dozadu. Nebo mi něco uniká?
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ě
Programátor je až na konci vývojového řetězce, ty potřebuješ názor analytika.
Nebo řekni Chuckovi Norrisovi, ten to naprogramuje dávkovým souborem bat.
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.
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.
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.
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í
Vývoj programu
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 :)
Že by vážně taková aplikace neexistovala? Klidně bych se vsadil, že logistické firmy něco takového mají.
Pokud to bude desktopová aplikace pro Windows, tak klidně použij C#.
Oukej, já doufal v C#. Takže tedy C# a Visual studio. Toto byl jen příklad.. Ve skutečnosti bude aplikace fungovat na takový způsob, ale né na palety. Mám kontakty na hodně lidí z odvětví na které bude appka mířit a všichni si stěžují, že nic takového ještě není a že si za to klidně zaplatí.
Tak si taky zjisti, kolik takových lidí je a kolik by za to byli ochotni zaplatit. Abys pak nezjistil, že tvoji půlroční práci by dohromady ohodnotili na 50 000 Kč.
Jasný, vše si teprve zjistím. Ale mohlo by to mířit na velké firmy. Každopádně o tom ještě brzo mluvit, musím to pořádně vymyslet. Díky za řešení
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...
Díky za radu!
Ten mobil je spíš výhled do budoucna, pokud se appka na desktopu chytne. Ani si nemyslím, že by to bylo něco těžkého. Dva vstupy, vytáhnou data z databáze a pošlou výstup ano-ne.. Ovšem je potřeba pak zakomponovat nějak to, aby to ukázalo, jak poskládat tak, aby se to tam vešlo. To už asi tak jednoduché nebude.
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...
Když nevíme, co ten program má dělat, logicky ani nelze doporučit programovací jazyk.
Jasný, chápu, má chyba. Příklad na nějak tak stejný způsob jsem napsal do komentáře nad tímto. Díky :)
Na dotaz tak jak je položený existuje odpověď:
Jdi tam nevím kam přines to nevím co.
Napadá mne, kdysi se mluvilo o nějakém nástroji Soukup Graphic Preprocessor.
Nebylo to něco podobného co chceš řešit ty?
Snad nemyslíš Baltazara?![]:)](https://static.poradna.net/images/smiley/evilsmile.gif)
Dlouho jsem o něm neslyšel.
https://cs.wikipedia.org/wiki/Baltazar_(programovací jazyk)
Chápu :) Měl jsem to napsat, má chyba. Napsal jsem příklad v komentáři nad tímto :) Díkyy (y)
Chápu - to je skutečně něco jiného. Po přečtení dotazu jsem měl dojem, že chceš napsat něco co usnadní psát program, případně to bude průběžně kontrolovat.
Když se do toho chceš pustit, nenech se odradit, kdo ví, kdy se ti to co se při tom naučíš může v budoucnu hodit.
V podstatě skoro každý programovací jazyk by to měl zvládnout, některé jsou jednodušší, jiné složitější. (teda chápu, že napsat v Brainfuck-u program, co ti to přez G-code vykreslí na CNC asi není ideální cesta, ale taky by to asi šlo![]:)](https://static.poradna.net/images/smiley/evilsmile.gif)
obecně bych se vyhnul této kategorii https://en.wikipedia.org/wiki/Category:Esoteric_programming_languages ![]:)](https://static.poradna.net/images/smiley/evilsmile.gif)
)
Pokud to C# jakobys neměl, uvažoval bych spíš třeba o Pythonu, který spoustu věcí umožňuje dělat jednodušeji, je populární a je k němu spousta knihoven (i na generování obrázků třeba). Je asi o něco pomalejší, než C#, ale na tohle by to vadit nemělo, zato se v něm píše rychleji a snáz se ladí = kratší vývoj takovýchto jednodušších programů.
Díky! Mrknu podrobně na porovnání Pythonu a C#
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…
Prvně to vyřeš algoritmicky, pak můžeš uvažovat nad jazykem, do kterýho to přepíšeš.
Jseš si jist, že to opravdu zvládneš? Nevzal sis moc velký sousto?
Vzal jsem si velké sousto. Počítám s tím, že to bude trvat dlouho. Ale jsem rád, že mám cíl a můžu se to na tom učit. Zároveň si myslím, že by program mohl mít budoucnost. Při nejhorším si budu muset sehnat seniora, který mi s tím pomůže.
A nebylo by lepší udělat prvně pár menších projektů?
Ta tvoje optimalizace - řešící problém co chceš programovat - bude 2D nebo 3D? Pokud s tím nemáš předchozí zkušenosti, bude to náročný.
Ten poslední výstup poskládání, bych rád dal do 3D grafického zobrazení. Nějakého basic.. Ale to už sám určitě neudělám, celkově tenhle výstup o možnostech poskládání asi vůbec sám nezvládnu.
Bude těch variant, jak to tam naskládat hodně? Pokud by jich bylo jen pár, možná by ten problém šel obejít tak, že by se to "natvrdo" uložilo a pak by se jen vybralo zvolený řešení.
Ale pokud těch variant budou třeba stovky, pak budeš potřebovat pořádně studovat. Sám bych nevěděl, jak na to.
P.
Těžko se o tom mluví, když tu veřejně nechci vysvětlit podstatu problému. Ale variant bude dost.. Každý kontejner bude různě velký a palety též různě velké, tudíž variant asi bude dost :/
Tak v prvnim kroku udelat databazi palet a kontejneru a hledat v ni je celkem snadny krok.
pak pridat test na vahu je taky easy
pridat "silne orientacni" test, zda soucet objemu palet neni vetsi je taky snadne - pokud je, tak se to sichr nevejde
a pokud se tam daji naskladat trivialne (vyzkouset par zakladnich variant - podelit delky a zaokrouhlit dolu na cela cisla ), tak je to fajn a sichr se to vejde
a pokud by se objemem vesly a trivialne ne, tak muze zkusit neco pokrocilejsiho, jako treba kombinace dve rovne, jednu nastorc a tak ... to uz je pokrocilejsi a pripadne tam mrsknout i neco s 3D skladanim a generickymi algoritmy pro rozhodnuti tech veci mezi tim, pokud si bude hodne troufat
A zobrazovani taky muze udelat po nekolika ruzne slozitych krocich.
Přesně tak.. Samozřejmě tu nejde opravdu o kontejnery a palety ( Přesný účel programu tu nechci popisovat, to jistě chápete) Ale "kontejnerů" bude opravdu jen 6, tudíž vypsat databázi nebude těžké.. Palet už samozřejmě může být opravdu dost, tudíž nevím, zda to vypíšu ručně, nebo to zkusím přepojit přes nějakou databázi na internetu. Lehčí, ale delší bude to vypsat. Takže toto nevidím jako tu těžší část. Ale poslední výstup se srovnáním palet tak, aby se to vešlo, nebude jednoduché a sám to asi nezvládnu.
Taky pozor na to, zda krabice/palety můžou být v libovolných polohách. A pak ještě pozor na to, když rozměry vyjdou natěsno, např. tři krabice vedle sebe -> 110 cm a vnitřní rozměr kontejneru -> 111 cm; zdánlivě to stačí, ale když se tam ty krabice budou dávat, už nezbude dost prostoru na ruce.
Ve skutečném případě nebude ani jedna tato možnost hrozbou, "paleta" bude moct být jen v jedné poloze a nebude se zde pokládat ručně, takže jí lze dát na těsno. Omlouvám se, že ve skutečnosti neřeknu o co jde, ale je to podle mě dobrý nápad a knowhow, kterého by někdo mohl zneužít, kdybych ho tu veřejně napsal. Tudíž tyto věci asi spíš pak budu řešit s nějakým specialistou, se kterým se o nápad podělím a budu po něm chtít pomoct s tímto konečným "poskládáním"
Nedokážu identifikovat, zda v tom segmentu, kde se pohybuješ něco takovýho už neexistuje. Ale obecně, nějaká optimalizace 3D rozmístění krabic v kontejneru musí existovat už drahný léta; to využívá (nejen!) letecká a lodní doprava.
Jasný, ohledně krabic v kontejneru vůbec nevím, to asi něco opravdu existuje. Já to ale použil jen jako příklad, ve skutečnosti jde o úplně něco jiného. V tom mém segmentu tento program opravdu chybí, mám známého, co v tomto segmentu má firmu a samozřejmě i kontakty na vztahy s ostatníma v tomto segmentu. A prý si všichni říkají, proč toto ještě nikdo nevytvořil, že by jim to strašně ulehčilo práci. Ovšem stěžují si na to "zaměstnanci" mezi sebou a nepošlou to mezi management, tudíž se to stálo ještě nevytvořilo.
A management na to: proč jste to neřekli dřív? Ten program už existuje a stačí ho koupit
Toto už mám zjištěné.. na 100% takový program neexistuje. Je možné, že ho někdo vyvíjí na přání společnosti, ale to si nemyslím. Ale já se na tom rád neučím něco málo z programování a uvidím konečně taky něco jiného než SAP a SAPí integrace. Takže na tom ztratím akorát svůj čas, který bude zároveň jako studium programovacího jazyka a když to dobře dopadne, bude dobře placený.
To by ses divil, kolik existuje různých softwarových produktů, o kterých nemáš ani tušení.
Nepřijde mi to moc pravděpodobný.
Kdybys kápnul na nějakou novinku; pak chápu, že ještě nemusí existovat optimální způsob a dá se přijít s novým řešením. Ale v případě "krabice do kontejneru" to prostě na nový, dosud neexistující řešení fakt nevypadá.
Opravdu to tak je, mám v tomto odvětví mnoho názorů od lidí, kteří by to využili, ale nevědí o ničem takové, že by to existovalo. Dělají to způsobem, že to prostě nějak poskládají. Ale se ztrátou času a nervama.
To je právě ta podstata, to ostatní kolem je víceméně bižuterie. Takže nepůjde o pomoc, ale o vyřešení problému.
To já jen tak, aby to bylo jasný.
¨
Tohle se dělá tak, že si program stáhne aktualizaci z internetu a pak si to drží u sebe v lokální databázi.
Ty jen provedeš aktualizaci na netu - přidáš položky, na nějaké místo dáš informaci, že došlo k aktualizaci a program bude vědět, že si má stáhnout nový seznam.
Jde o to, zda mohou být bedny a palety v kontejneru libovolně, nebo zda tam musí být naskládány s ohledem na logistiku - třeba pro jednoho zákazníka pohromadě nebo se dodržuje pořadí podle zákazníků. Abys pak nedojel k prvnímu zákazníkovi a nezjistil, že musíš kontejner celý vyskládat, aby ses dostal k paletě, která je úplně v zadu.
Po těchto konverzacích se toho ještě víc bojím..
No bude to běh na dlouhou trať a výzva, tak snad se s tím nějak poperu. Každopádně díky všem za rady. Když občas čtu ty poradny, kde hned padají odpovědi typu - najdi si to na google, když o tom nic nevíš, tak do toho nelez apod. Tak jsem se toho trochu bál.
Sice mám nějaký ten "opravdu mini" základ v pár příkazech, ale zase třeba vůbec netuším, jak se řeší grafické zobrazí toho programu. Aby to neběželo někde v příkazové řádku. Takže to opravdu nebude lehkéé
A taky nezapomínej, že vytvořením programu to zdaleka nekončí. Prodáš to firmám a ty určitě budou chtít mít podporu. Co budeš dělat, když ji třeba budou požadovat 24/7 a vyřešení problému do 2 pracovních dnů?
Co když budou chtít mít k tomu dokumentaci? Máš někoho, kdo ti ji napíše a třeba i přeloží do angličtiny?
Toto bych asi řešil v případě, že tu aplikaci už budu mít. Nejdřív vypustit nějakou testovací verzi a až to bude vychytané, tak pak nabízet roční licence. Ale děkuji za postřeh, určitě toto pak bude potřeba řešit. Ale myslím, že až se dostanu do bodu, kdy toto budu řešit, tak už program nebudu vyvíjet sám, tak ohledně toho budu mít snad i nějakou pomoc, která už třeba nějaký program někdy vypustila.
Takže vlastně chceš vyřešit tzv. Bin Packing Problem - tož hodně štěstí! Ani ne tak s programováním, ale především s návrhem algoritmu!
Je samozřejmě nesmysl tvrdit, že žádný takový SW neexistuje - viz třeba https://www.easycargo3d.com/cs/ nebo https://retailnews.cz/2020/12/14/optimalni-paletizace-jako-zdroj-uspor-a-efektivity/:
Něco o Bin Packing Problemu se dočteš třeba v téhle disertační práci...
Jak už jsem říkal, příklad kde uvádím palety a kontejner je jen příklad. Ve skutečnosti se nejedná o palety a ani o kontejner. Tudíž je to úplně mimo tento SW.. Chápu že to bude opravdu těžké.. Možná by bylo jednodušší, kdybych se o nápad podělil s nějakým senior programátorem, kterému by se to zalíbilo a šel by do toho se mnou
Potřebuješ především odborníka (či spíše odborníky) na algoritmizaci problému s matematickým VŠ vzděláním. To, co chceš naprogramovat (aspoň tak jak jsi to popsal) je totiž obecně velmi složitý problém (tzv. NP těžký problém), který lze řešit jen heuristickým algoritmem. Do téže množiny patří např. úloha obchodního cestujícího. Na týhle úrovni problémů si bez znalosti matematiky z VŠ vzdělaní ani neškrtneš.
Pokud bych ale chtěl jen program, do kterého zadám ty dvě vstupní hodnoty, ono si to vytáhne z databáze rozměry a řekne mi, zda se množství palet do kontejneru vejde (ANO-NE) tak to tak moc složité není, že ?
No, budeš se asi divit, ale složitost bude v podstatě stejná.
Příklad (po jednoduchost ve 2D):
* máš čtyři palety 2,5 x 3 m, plocha palet je 4 * (2,5 * 3) = 30 m2.
* máš kontejner 4 x 9 m, plocha kontejneru je 4 * 9 = 36 m2.
Plocha palet je o dost menší, než plocha kontejneru (konkrétně zde 83,3 %), přesto ty palety do kontejneru nenaložíš. Těžko to zjistíš bez toho, že by ses v tom SW pokusil ty palety poskládat.
A teď to ještě budeš mít ve 3D s různou velikostí palet...
V mém případě to ale nebude ve 3D.. Změním tedy příklad, aby to bylo více pochopitelné.. Máte Nákladní automobil, který má jako návěs dvě plochy za sebou, čisté plochy (obdelníkové - čiže jako normální návěs, ale bez plachty. Tudíž je tu jen podlaha a kola. A na ty dvě plošiny naložíte vždy cca 6-8 krychlí. Každá krychle se totiž liší jen o několik desítek centimetrů, z toho důvodu jich tam vždy bude 6-8. Tudíž zde nezáleží na výšce a objemu krychle. Spíš pouze na šířce a délce.
Vlastně ani né tolik na šířce.. Jelikož krychle budou za sebou.. Nikdy né vedle sebe.. A každá krychle je stavěna tak, aby tolik nepřečnívala z návěsu.. Takže nám vlastně jde jen o délku.
Takto popísaný problém vyzerá byť veľmi easy...Na to Ti stačí v ruke kalkulačka a nepotrebuješ špecializovaný sw...
Ať teda vedení firmy koupí zaměstnancům kalkulačky, to vyjde levněji než software.
Na takto popsaný problém opravdu nepotřebuješ speciální SW, na to stačí malá násobilka. Asi někdo z nás (nebo oba dva) něco nechápe...
Nechci tu psát přesnou podstatu programu, proto Vám to přijde blbé a zbytečné. Ono to ve finále není tak jednoduché. Každopádně chápu Vás, že to nechápete.
A co je cílem té optimalizace? Naložit co nejvíc kusů? Nebo naložit náklad tak, aby se v definovaným pořadí (např. pro zákazníky A, B C) vyskládal? Je jedno, zda se bedna uloží na přední nebo zadní návěs?
Když mi dodavatel řekne, že mám naložit tohle a tohle, tak abych to zadal do appky a mohl mu říct, to se vejde a to se nevejde. V těžší fázi by mi to řeklo.. Ano, to se vejde, ale naskládej to takhle. A také do toho zahrnout kdy a co se kde bude vykládat (přesně jak jste psal, něco se vyloží dřív, proto to dám dopředu. Ta konečná fáze toho třídění bude těžká a bude na to potřebný nějaký IT matematický expert, v tom máte pravdu :/
Na tu poslední fázi budeš hlavně potřebovat naprogramovat trasu - zákazníky poskládat tak, abys měl co nejkratší trasu a současně vyhověl jejich otevíracím hodinám (případně oknu, kdy je schopný to zákazník přebrat).
To už není potřeba, to už se řeší zákazník sám a jinak.. V tomto případě zjednodušeně řešeno.. Budu zadávat palety od první k poslední podle toho, kterou vyložím jako první a jako poslední. To se zohlední při tom, jak program určí každé paletě místo.
Takže znovu sa dostávame okľukou k "paletizácii", resp. logistike nakladania a vykladania "niečoho"....
Mám pocit, že chceš vymyslieť niečo, čo tu už dávno existuje (možno v mierne inej podobe)....
Tohle se mi zdá už minimálně třetí varianta toho, co se má vlastně řešit; myslím tím, že je to minimálně třetí popis zadání.
Zdá se mi, že prostě stačí naložit ty palety v opačným pořadí, než se budou z návěsy vykládat. A jestli se tam na návěs vejdou všechny, to se ověří lehce tím, že se sečtou jejich rozměry + (případný) mezery a porovná se to s délkou návěsu.
Možná je to překlep možná to myslíš jinak, možná to špatně chápu, ale:
Čekal bych, že to co se vyloží dřív se dá na návěs dozadu. Nebo mi něco uniká?
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ě
Programátor je až na konci vývojového řetězce, ty potřebuješ názor analytika.
Nebo řekni Chuckovi Norrisovi, ten to naprogramuje dávkovým souborem bat.![]:)](https://static.poradna.net/images/smiley/evilsmile.gif)
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í