MORIARTY: Uplny zacatecnik potrebuje co nejmene barier a prekazek mezi prazdnym souborem a programem, co vypisuje na konzoli "hello, world". Z tohoto hlediska je python zcela idealni. C++, C# a dalsi jazyky, kde musis nejdriv napsat deset "magickych" radek, kterym vubec nerozumis, jen aby to nejak fungovalo, jsou na nejake uceni naprosty opak, protoze to cloveka akorat odradi. Tim spise, kdyz se do toho tahaji takovy zverstva jako pointery. Za me na zacatek Python.

Nebo na to jit z druhe strany, nezkusenosti s programovanim naopak vyuzit a naucit se Haskell, ale to je druhy extrem.

Já si tedy nedovedu představit, že bych se znovu učil programovat, ale asi bych začal přímo c++. Ono se to dá naučit a pochopit za pár dní. A to i s pointerama, polema a mallocem. Sice to pak ve vyšších programovacích jazycích člověk nepotřebuje, ale aspoň zjistí, jak to funguje. (a třeba pochopí, jakej je v C# rozdíl mezi List a Array a proč se do Array nedají přidávat pole, jak se mi tu včera vztekal jeden kolega).

LARS_GUNNER: Nevím no, psal jsem hodně dlouho v C# a v poslední době jsem zkusil Python, malý projekt stránek ve Flasku a jako jo, vplul jsem do toho rychle, ale nějaký větší věci bych stejně mnohem radši dělal v C#.
Může to být samozřejmě praxí, ale některý ty věci na Pythonu jako třeba odsazení místo závorek, na který si musíš dávat dost bacha když kopíruješ kód, mě celkem iritovaly. Pak taky teda nevím jestli je na to nějaký lepší IDE než mám já VSCode, ale oproti Visal Studiu od MS je to fakt slabý, co se týče podpory pro psaní kódu.
Další věc, že se ten program většinou v pohodě pustí s chybou a spadne až když jede, to mi nepřijde pro začátečníka moc user friendly.
Neskutečný bordel je obávám se právě to, co tam začátečník bude mít, než získá nějaký ty návyky a disciplínu.
Prostě pro začátečníka mi přijde C# jasnější, proměnné tam mají svůj typ, když strkáš do funkce něco, co tam nepatří, tak tě to hned upozorní. Použití základních knihoven mi taky přijde víc user friendly v C# a Visual Studiu, kde ti to hned nabízí možnosti. Prostě komfort, kterej teda u Pythonu rozhodně nezažívám. Ale jak jsem psal, může to být všecko jenom tím, že jsem na něco prostě zvyklý a z Pythonu mám kulturní šok. :)

SINTAKRA: Python není vůbec špatná volba co se týká jednoduchosti a pracovního uplatnění.

SINTAKRA: Souhlas že C# bude nejjednodušší na naučení. Java je taky dobrá volba, z hlediska další zaměstnatelnosti asi vede. Python bych pro začátek radši vynechal. :)

SAJAGI: ehm... tak po rozchozeni remote debuggeru jsem dostal
Spatial types and functions are not available for this provider because the assembly 'Microsoft.SqlServer.Types' version 10 or higher could not be found.
a to uz se resit da (spatial types se totiz populuji jen u nekterych zaznamech a ja mam lokalne evidentne vse, co potrebuji) - vyjimku zrejme nejak sezere UI

SAJAGI: tak i bez using je vysledek naprosto totozny
pro id 2421570 je na win serveru posledni EF log "Closing connection" zatimco z meho pc do stejne databaze dostanu i moje dalsi "logy" a data jsou normalne nacteny. (a prave ten pruser je, ze pro vetsinu id to proste projde stejne na obou mistech)

SAJAGI: doufam, ze ne - LeadId je bindovane na input v user controlu - ale zkusim se na moment zbavit using a uvidim, co to s tim provede

FONTAN: Pro jistotu se zeptám, nemáš kolem toho nějaký try-catch wrapper, který ti zahazuje výjimky? To by vysvětlovalo, proč ti metoda skončí v polovině a zároveň se ti zavře připojení díky tomu using bloku.

muzu se po****

nenarazil jste nekdy nekdo na to, ze vam na nejake masine "nahodne" skoncila funkce, aniz by dodelala svoji praci? ...

mam tohle (wpf aplikace, EntityFramework6, logovani je pridane ted):

private int leadID;
        public int LeadID {
            get { return leadID; }
            set
            {
                if (value != leadID)
                {
                    leadID = value;
                    using (var db = new FormFillLMSEntities(GlobalAppData.GetConnection(AllowedDB.LMS)))
                    {
                        db.Database.Log = s => ConsoleMessages.Add(new ConsoleLog() { EventDate = DateTime.Now, Source = "db", Message = s });

                        ConsoleMessages.Add(new ConsoleLog() { Message = "Lead prefetch: " + leadID.ToString() });

                        var _lead = db.CEFs.SingleOrDefault(c => c.ID == leadID);

                        ConsoleMessages.Add(new ConsoleLog() { Message = "Lead fetched: " + (_lead!=null ? _lead.ToString() : "null") });

                        Lead = _lead;
                    }

                    ConsoleMessages.Add(new ConsoleLog() { Message = "Lead after fetched: " + (Lead != null ? Lead.ToString() : "null") });

                    this.RaisePropertyChanged(() => Lead);
                    this.RaisePropertyChanged(() => LeadID);
                }
            }
        }
        public virtual CEF Lead { get; set; }

a - na vyvojovem pc win10 vse jde jak bych tak nejak ocekaval

ale - na testovaci masine Win Server 2016 Datacenter mi to funguje tak, ze:
pro vetsinu leadid to vrati ocekavany vysledek (tj. nic, pokud lead neexistuje a lead, pokud existuje) s patricnym logovanim, ALE pro nektere id to "skonci" hned po/pri/v zavolani var _lead = db.CEFs.SingleOrDefault(c => c.ID == leadID);

a to tak, ze entityframework zaloguje uplne totez, co vzdy, vcetne close connection (a v sql profileru vidim, ze to ten query orpavdu nahodi), ale _lead se nenastavi a ConsoleMessage z lead fetched se nezavola

vubec netusim, co hledat, protoze mi to samozrejme funguje i tehdy, kdyz si dev versi napojim na tu samou db, jako nefunguje ta testovaci

Toto by malo fungovat aj na sietove priecinky >> https://docs.microsoft.com/en-us/dotnet/api/system.io.directory.exists?view=netcore-2.1, s tym ze tam potrebujes mat osetrenie na security...

Pridal by som tam check na nieco ako je popisane v odpovedi na tomto stackoverflow-e :)
c# - How to check if the application has access to a Directory? - Stack Overflow
https://stackoverflow.com/...ions/15656058/how-to-check-if-the-application-has-access-to-a-directory

Neřešil jste někdo jak otestovat kód (.NET Core 2.1), který přistupuje ke sdílené síťové složce (SMB)?
Potřeboval bych v NUnit napsat integrační testy, které budou manipulovat s dostupností síťové složky.

Mám napsaný program, který sleduje síťovou složku přes FileSystemWatcher.
Zatím jsem si napsal testy, které pracují se složkami na disku, jenže tímhle způsobem není možné
otestovat, že složka přestane existovat (Složku na disku nejde odstranit, pokud jí má FileSystemWatcher už otevřenou).

Nebo na to jdu úplně blbě, neměl bych pro síťovou složku používat FileSystemWatcher a
měl bych raději periodicky prohledávat složku sám přes Directory.GetFiles nebo EnumerateFiles?

LIQUID_SOUND: já bych si život nekomplikoval a vyřešil to pomocnou proměnnou.

dim pom as Boolean = True
While pom

'udelej neco   
'a tady ve zvlastnim for zvalidovat, jestli jsou vsechny bunky na false a kdyz ano, tak nastavit pom = False pro ukonceni while cyklu

End While