Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Hanz 19. 03. 2015, 13:58:32
-
Dobrý den,
pracuji na DPP. Je tedy u mě rozumné mít legální software. Abych byl kompatibilní se zadavatelem úkolů, měl bych používat minimálně VS2010. Mám pocit, že v express verzi můžu vytvářet i komerční řešení, ale ta má omezení. Zjistil jsem navíc, že existuje VS2013 Community edition, která má v licenci:
Visual Studio Community je určeno primárně pro nekomerční komunitní projekty a je zcela zdarma pro:
•jednotlivce, kteří pro sebe vyvíjejí vlastní aplikace (placené i free),
•vývojáře, kteří přispívají do open-source projektu,
•studenty, učitele, třídy, online kurzy – zkrátka kohokoliv v akademické sféře,
•Malé společnosti (obrat do 1 mil USD), které mají 5 nebo méně vývojářů společně pracujících na vlastních komerčních nebo nekomerčních aplikacích
Nerozumím ale tomu poslednímu bodu: smím ho, prosím, na DPP legálně používat?
Děkuji za Váš názor.
Hanz
-
Pokud tvůj "zadavatel úkolů" je větší firma, máš s community edition smůlu, tu můžeš komerčně použít pro vývoj menších retailových aplikací, ne na zakázku pro velkého objednatele. Ale licenční podmínky používání produktů MS zjistíš nejlíp na MS, tady není vhodné místo.
Co přesně ti ve verzi Express chybí?
-
...pracuji na DPP. Je tedy u mě rozumné mít legální software...
Jestli děláš na DPP, tak by ti měl takovéhle prostředky poskytnout v první řadě zaměstnavatel. Jedná se o tzv. závislou činnost, která se má provádět na prostředcích zaměstnavatele a na jeho rizika.
Jó, kdybys dělal na živnosťák, je to jiná věc.
-
Můžu se zeptat, jestli DPP nebo DPČ je závislou činností i při nižším úvazku? Jsme totiž primárně v plném invalidním důchodu.. Díky
-
ano.
-
A to se týká i HW ? Díky
-
A to se týká i HW ? Díky
Ano. Je obvyklé, že ti zaměstnavatel na DPP i DPČ poskytne vhodný HW i SW.
-
Chvála Bohu, v žádné.
-
pracuji na DPP. Je tedy u mě rozumné mít legální software.
To je rozumné vždy.
-
Chvála Bohu, v žádné.
+1
Používám Netbeans (Java, C++, SQL…), což je svobodný software – jeho licence mě neomezuje v tom, k jakému účelu ho budu používat. I když budu ta největší korporace na světě, stále pro mne platí stejné podmínky.
-
Chvála Bohu, v žádné.
+1
Používám Netbeans (Java, C++, SQL…), což je svobodný software – jeho licence mě neomezuje v tom, k jakému účelu ho budu používat. I když budu ta největší korporace na světě, stále pro mne platí stejné podmínky.
Coz nemeni nic na tom, ze na C# je lepsi VS.
-
Chvála Bohu, v žádné.
+1
Používám Netbeans (Java, C++, SQL…), což je svobodný software – jeho licence mě neomezuje v tom, k jakému účelu ho budu používat. I když budu ta největší korporace na světě, stále pro mne platí stejné podmínky.
Coz nemeni nic na tom, ze na C# je lepsi VS.
Probůh, k čemu C#? To bych už rovnou mohl používat jako OS windows ;D
-
Coz nemeni nic na tom, ze na C# je lepsi VS.
Mně se na C# osvědčil Vim.
-
Chvála Bohu, v žádné.
+1
Používám Netbeans (Java, C++, SQL…), což je svobodný software – jeho licence mě neomezuje v tom, k jakému účelu ho budu používat. I když budu ta největší korporace na světě, stále pro mne platí stejné podmínky.
Coz nemeni nic na tom, ze na C# je lepsi VS.
Probůh, k čemu C#? To bych už rovnou mohl používat jako OS windows ;D
:o
Windows jako OS?
NEMOHL
-
Chvála Bohu, v žádné.
+1
Používám Netbeans (Java, C++, SQL…), což je svobodný software – jeho licence mě neomezuje v tom, k jakému účelu ho budu používat. I když budu ta největší korporace na světě, stále pro mne platí stejné podmínky.
A ty seš nějakej krajně levicovej, že ti vadí opak?
-
Coz nemeni nic na tom, ze na C# je lepsi VS.
Mně se na C# osvědčil Vim.
Tomu se říká neschopnost.
-
Chvála Bohu, v žádné.
+1
Používám Netbeans (Java, C++, SQL…), což je svobodný software – jeho licence mě neomezuje v tom, k jakému účelu ho budu používat. I když budu ta největší korporace na světě, stále pro mne platí stejné podmínky.
A ty seš nějakej krajně levicovej, že ti vadí opak?
Nevím, jak on, ale já třeba ano. To píšeš stylem, jako kdyby třeba komunismus byl špatný.
-
Coz nemeni nic na tom, ze na C# je lepsi VS.
Mně se na C# osvědčil Vim.
Tomu se říká neschopnost.
Neschopnost instalovat VS na Ubuntu nebo tvoje neschopnost pracovat s Vimem?
-
Tvoje neschopnost používat IDE. Až se tím jednou budeš živit, tak třeba zjistíš, že VIM není to nejlepší na programování.
-
Tvoje neschopnost používat IDE. Až se tím jednou budeš živit, tak třeba zjistíš, že VIM není to nejlepší na programování.
A co Vimu podle tebe chybí?
-
Osobně používám Visual Studio Professional with MSDN, cena je cca 1200 USD. Na většinu věcí ale stačí edice Express, nyní Community.
Ohledně licencování: VS 2013 Community můžete použít pokud pracujete sám (na DPP nebo ŽL). Výjimkou je situace kdy pracujete pro korporaci, tedy firmu s více než 250 PC nebo uživateli, nebo s obratem více než 1M USD. V takovém případě můžete použít VS Express, například Visual Studio Express 2013 for Windows Desktop. To sice některé věci neumí, ale většinou postačí, je zdarma, a není nijak omezené ohledně zákazníka pro kterého pracujete.
https://www.visualstudio.com/support/legal/dn877550
-
Co přesně ti ve verzi Express chybí?
Pouzivam Expess verzi pro OS projekt. Chybi mi, ze nemuzu vytvorit rozumny .msi instalator. I kdyz pouziju WIX,
tak stejne nemuzu do do instalatoru pribalit MSVC runtime knihovny. Chybi mi k tomu nejaky mapovaci soubory ktery nejsou soucasti Expessu.
-
Chvála Bohu, v žádné.
+1
Používám Netbeans (Java, C++, SQL…), což je svobodný software – jeho licence mě neomezuje v tom, k jakému účelu ho budu používat. I když budu ta největší korporace na světě, stále pro mne platí stejné podmínky.
Coz nemeni nic na tom, ze na C# je lepsi VS.
Probůh, k čemu C#? To bych už rovnou mohl používat jako OS windows ;D
No to už je jiná otázka :D Ale na C# bych asi nic jinýho nepoužíval.
-
Odporucam ti napisat do microsoftu, oni su tam dost ochotni ked si chce niekto nieco kupit.. (aspon mam taku skusenost, sice iba raz, ale vsetko mi ochotne vysvetlili)
Inak toto forum ide dole vodou. Sem chodim ked mam prilis dobru naladu (lebo kto vysoko lieta nizko pada, tak si ju musim trosku zhorsit). Jasne pise o kompatibilite so zadavatelom ukolu a zvrhne sa to na c#, vim a neviem co.
-
Inak toto forum ide dole vodou. Sem chodim ked mam prilis dobru naladu (lebo kto vysoko lieta nizko pada, tak si ju musim trosku zhorsit). Jasne pise o kompatibilite so zadavatelom ukolu a zvrhne sa to na c#, vim a neviem co.
Nemohu za to, že pokaždé, když se zmíním o editoru Vim, má někdo potřebu mě napadnout a označit mě za neschopného používat IDE.
-
Odporucam ti napisat do microsoftu, oni su tam dost ochotni ked si chce niekto nieco kupit.. (aspon mam taku skusenost, sice iba raz, ale vsetko mi ochotne vysvetlili)
Inak toto forum ide dole vodou. Sem chodim ked mam prilis dobru naladu (lebo kto vysoko lieta nizko pada, tak si ju musim trosku zhorsit). Jasne pise o kompatibilite so zadavatelom ukolu a zvrhne sa to na c#, vim a neviem co.
:) c# a vim, to se dá ještě snést... horší je když se to zvrhne na filozofování o náladě.
-
c# a vim, to se dá ještě snést... horší je když se to zvrhne na filozofování o náladě.
Otazka bola polozena jasne, ci nie? K veci je asi prvych 6 komentarov, ostatne sa mozu zmazat (vratane toho mojho, ja sa nehadam).
-
Aby šlo udržet větší projekt dlouhodobě rozvíjitelný, je při téměř každém zásahu potřeba refaktorovat. Někdy jen zpřesňovat názvy proměnných/metod, většinou rozpadat dlouhý kód do správně pojmenovaných metod, měnit jejich parametry, zpřesňovat názvy tříd, seskupovat jednotlivé příbuzných parametry do tříd, atd. atd. Vlastní programování algoritmů je v běžném byznys softwaru to nejmenší, daleko víc práce je s dlouhodobým udržováním kódu.
A tohle si vůbec nedovedu představit bez pořádného IDE, které to vše umí na pár kliknutí. V našem případě javy Intellij Idea, VS předpokládám umí s C# to samé.
-
Aby šlo udržet větší projekt dlouhodobě rozvíjitelný, je při téměř každém zásahu potřeba refaktorovat. Někdy jen zpřesňovat názvy proměnných/metod, většinou rozpadat dlouhý kód do správně pojmenovaných metod, měnit jejich parametry, zpřesňovat názvy tříd, seskupovat jednotlivé příbuzných parametry do tříd, atd. atd. Vlastní programování algoritmů je v běžném byznys softwaru to nejmenší, daleko víc práce je s dlouhodobým udržováním kódu.
A tohle si vůbec nedovedu představit bez pořádného IDE, které to vše umí na pár kliknutí. V našem případě javy Intellij Idea, VS předpokládám umí s C# to samé.
To nevieš, že Kit píše dokonalý kód na prvý pokus? ;)
-
Kita jsem pristihl, ze nevi jak propastny rozdil je mezi .NETem a MONO projektem. Od nej si prosim nenechte radit pokud nechcete blbe skoncit :)
-
Kita jsem pristihl, ze nevi jak propastny rozdil je mezi .NETem a MONO projektem. Od nej si prosim nenechte radit pokud nechcete blbe skoncit :)
Kdy? Máš nějaké divné informační zdroje.
Kromě toho se to vůbec netýká tématu, tak do mne nerýpej.
-
Z toho je videt, jak komerce pozira sebe samu; misto aby programoval, resi licence. Chudacek. Vitezstvi open source je neodvratne.
-
Stejně je divný, že u Visual Studia se někdo vůbec zabývá licencí, když tu Windowsáckou někdo furt jen zpochybňuje. ;D
-
Tvoje neschopnost používat IDE. Až se tím jednou budeš živit, tak třeba zjistíš, že VIM není to nejlepší na programování.
Hmm... tak VS2010 ani neumí skládat if/while a pod.... zatímco ve vimu můžete snadno mít např. rename-refactoring, našeptávání... vim+tmux je velice solidní IDE pro neGUI věci. U C# může být mono problém, to je fakt.
Což ovšem neplatí pro někoho, kdo nemá náladu se ve vimu učit...
-
(mám samozřejmě na mysli C# ve VS2010, skládání pro C++ to má lepší, jestli se pamatuju dobře)
-
Panove, panove, panove...
nedavno tu byla podobna debata. Jeden tu tvrdil, ze vim nebo podobny je uplne dostacujivi i na velke projekty. Jeho velky projekt mel snad 4000 souboru. Tak sem se tenkrat mrkl na jeden muj maly projekt a ten mel souboru 40 000. Takze bych vam vrele doporucil, abyste krom svych machrovsky sebejistych tvrzeni o tom, ze vim nebo vs jsou jedine pouzitelne, uvadeli take to, k cemu to pouzivate.
Ve vimu sem napasal ledacos a pouzivam ho temer denne a je to opravdu fajn editor i bez ruznych specialnich pluginu, ale na praci na projektech o tisicovkach az stovkach tisic souboru, je ide temer nutna vec. Eclipse je chciply, chybovy, netbeans mi nikdy nesedlo, naopak vs mi prislo prekvapive fajn. I kdyz i ono ma chyby, ale ma mrte veci v zakladu, ktere treba do vimu musi doplnovat, coz se mi nechce. Navic potrebuju treba designer gui, rozumne vychytavky debugeru, debugovani mezi projekty v ruznych jazycich a solutionech. To, ze lidstvo preslo z textu na gui, melo svuj duvod, tak se mi prosim opravdu nesnazte namluvit, ze prehlednost a ovladatelnost pri solutionu o 50 projektech a 100 000 souborech ma vim vyssi, nez graficke ide.
Zkusensti mam s vs 2005, 2008, 2010, 2012, 2013, z toho 10, 12, 13 mam nainstalovany soucasne na vsech pracovnich strojich. Stejne tak mam na vsech linuxovych strojich vim a pouzivam ho k malym projektum, na kterych temer zavisi lidske zivoty.
-
Panove, panove, panove...
..... Tak sem se tenkrat mrkl na jeden muj maly projekt a ten mel souboru 40 000. vim vyssi, nez graficke ide.
ano, takove megalomanske debilni projekty existuji. Je to zavineno vetsinou neschopnym vedoucim projektu potazmo managementem. Lide, kteri v takovem projektu pracuji za to casto nemohou, nejak zivit se clovek musi.
Ze by to nekdo takovy ale musel vytrubovat na rootu mi prijde hloupe.
-
Panove, panove, panove...
..... Tak sem se tenkrat mrkl na jeden muj maly projekt a ten mel souboru 40 000. vim vyssi, nez graficke ide.
ano, takove megalomanske debilni projekty existuji. Je to zavineno vetsinou neschopnym vedoucim projektu potazmo managementem. Lide, kteri v takovem projektu pracuji za to casto nemohou, nejak zivit se clovek musi.
Ze by to nekdo takovy ale musel vytrubovat na rootu mi prijde hloupe.
Ono se to nezdá, ale pokud se vývojáři drží pravidla, že by třída neměla být delší než 65 řádek a řádky delší než 80 znaků, tak ty počty souborů naskakují docela rychle.
Na druhou stranu při změně jedné třídy není nutné refaktorovat půlku projektu, protože třídy jsou samostatné a pouze implementují nějaké rozhraní. Rozumný vývojář mění rozhraní jen výjimečně a postižené třídy se záhy ozvou nejen v IDE, ale i ve Vimu.
-
65 radek to hlupe pravidlo, asi prinesene z DOSu? To je o nieco viac ako 1 strana. Hore mozno 12 riadkov importy a mas 1 stranu a to smrdi nejakym antipatternom (napr anemic domain, alebo functional decomposition - to ked napr stari Cckari robia vo vime a zle sa im v tom orientuje :) ).
-
65 radek to hlupe pravidlo, asi prinesene z DOSu? To je o nieco viac ako 1 strana. Hore mozno 12 riadkov importy a mas 1 stranu a to smrdi nejakym antipatternom (napr anemic domain, alebo functional decomposition - to ked napr stari Cckari robia vo vime a zle sa im v tom orientuje :) ).
K čemu 12 řádek importů? Proč tolik? Třída by přece měla dodržovat SRP.
Obvykle stačí vyházet gettery a settery. Anemická doména se pak nekoná. Hlavně je nutné udržet všechny atributy jako privátní a mít co nejtenčí rozhraní s okolím.
Functional decomposition snad nemyslíš vážně. To smrdí statikou...
-
Tak Linux s nějakými 15M LOC malý projekt není a nějak pochybuju, že byl napsaný ve VS. Např. sám Linus používá MicroEmacs...
-
třída neměla být delší než 65 řádek a řádky delší než 80 znaků
To jsi vyhrabal ze které žumpy ?
Třída je dlouhá tak jak je potřeba a limit 80 znaků na řádek se týká textového režimu VGA a jehličkových tiskáren. Sociální případy s notebookem 1366*768 nejsou relevantní.
Optimální maximální délka jednoho zdrojáku je 1000 až 3000 řádků, ale není to dogma.
-
Obvykle stačí vyházet gettery a settery. Anemická doména se pak nekoná. Hlavně je nutné udržet všechny atributy jako privátní a mít co nejtenčí rozhraní s okolím.
A co na to říká Spring? :D
-
Obvykle stačí vyházet gettery a settery. Anemická doména se pak nekoná. Hlavně je nutné udržet všechny atributy jako privátní a mít co nejtenčí rozhraní s okolím.
A co na to říká Spring? :D
Nic. Je mu to jedno.
-
třída neměla být delší než 65 řádek a řádky delší než 80 znaků
To jsi vyhrabal ze které žumpy ?
Třída je dlouhá tak jak je potřeba a limit 80 znaků na řádek se týká textového režimu VGA a jehličkových tiskáren. Sociální případy s notebookem 1366*768 nejsou relevantní.
Optimální maximální délka jednoho zdrojáku je 1000 až 3000 řádků, ale není to dogma.
80 znaků má tu výhodu, že se mi vejdou 3 zdrojáky vedle sebe a ještě mi zbude extra pruh. Pokud to nepůsobí problémy, preferuji 80 znaků.
-
80 znaků má tu výhodu, že se mi vejdou 3 zdrojáky vedle sebe a ještě mi zbude extra pruh. Pokud to nepůsobí problémy, preferuji 80 znaků.
Má to výhodu i v tom, že když takový zdroják s limitem do 80 někde uveřejním, tak mě lidi nemají za kreténa, který si ten zdroják neumí naformátovat. Horizontální scrollování na webu nesnáším. Pro knihu je nutné ty řádky zkrátit ještě víc, takže používám soft-limit 65 znaků.
Na věci nic nemění fakt, že v editoru se mi na řádek vejde 115 znaků. Takže skoro dva zdrojáky vedle sebe, ale stejně je mám raději nad sebou.
-
Obvykle stačí vyházet gettery a settery. Anemická doména se pak nekoná. Hlavně je nutné udržet všechny atributy jako privátní a mít co nejtenčí rozhraní s okolím.
A co na to říká Spring? :D
Nic. Je mu to jedno.
Takže je s tím v pohodě a funguje bez problémů?
-
80 znaků má tu výhodu, že se mi vejdou 3 zdrojáky vedle sebe a ještě mi zbude extra pruh.
Kdo potřebuje vidět více dokumentů najednou, opatří si více monitorů nebo jeden větší, není to důvod reinkarnovat historické technické limity 80. Jedna z výhod vývoje IT je, že průměrný programátor si může dovolit slušný monitor(y).
Má to výhodu i v tom, že když takový zdroják s limitem do 80 někde uveřejním, tak mě lidi nemají za kreténa,
Komu se to nelíbí, prožene si to příslušným formátovacím nástrojem.
-
A co na to říká Spring? :D
Nic. Je mu to jedno.
Takže je s tím v pohodě a funguje bez problémů?
Zřejmě ano. Nepoužívám ho.
-
Má to výhodu i v tom, že když takový zdroják s limitem do 80 někde uveřejním, tak mě lidi nemají za kreténa,
Komu se to nelíbí, prožene si to příslušným formátovacím nástrojem.
Takové ignoranty, kteří nedodržují formátovací zvyklosti, mají spolupracovníci asi hodně rádi :)
Doufám, že máš aspoň správně nastavené filtry při odesílání do repozitářů.
-
Takové ignoranty, kteří nedodržují formátovací zvyklosti, mají spolupracovníci asi hodně rádi :)
80 znaků je historický relikt nikoliv současná formátovací zvyklost. Spolupracovníci nemají problém, současné běžné IDE zobrazí +-120 znaků najednou.
-
80 znaků je historický relikt nikoliv současná formátovací zvyklost. Spolupracovníci nemají problém, současné běžné IDE zobrazí +-120 znaků najednou.
Máš nějaký speciální důvod, proč dělat řádky delší než 80 znaků? Podle mne je to zcela zbytečné, nic tím neušetříš. Pouze znečitelníš program, protože oko se při čtení dlouhého řádku na něm neudrží a zbytečně přeskakuje na sousední řádky. Pokud udržíš řádky krátké, oči nemusí vykonávat při čtení vodorovný pohyb a neunaví se tak brzy.
Proč myslíš, že se novinové články píší do sloupků? Aby se to lépe četlo.
-
Hodí se to zvláště na parametry funkcí/metod a podmínky a zvyšuje to pravděpodobnost, že je funkce/metoda zobrazena celá najednou. Neustálé šoupání nahoru/dolu vyrušuje mnohem víc, než se podívat doprava, nemusím doufám zdůrazňovat že 80 znaků zvyšuje počet řádek.
Pro tvůj klidný spánek tě můžu ubezpečit, že když je toho moc, tak řádek rozdělím klidně načtyřikrát. Souvislost programování s novinami je asi nulová.
-
80 znaků má tu výhodu, že se mi vejdou 3 zdrojáky vedle sebe a ještě mi zbude extra pruh.
Kdo potřebuje vidět více dokumentů najednou, opatří si více monitorů nebo jeden větší, není to důvod reinkarnovat historické technické limity 80. Jedna z výhod vývoje IT je, že průměrný programátor si může dovolit slušný monitor(y).
Víc monitorů nepomůže, protože bych musel otáčet hlavou... to už vyjde nastejno jako přepínání mezi soubory. A 22"-24" FullHD monitor už je na hranici toho co dokážu najednou vnímat a s vyšším DPI bych stejně musel zvětšit písmo abych to pořádně viděl, takže to taky na moc nebude. Chápu, že s některými jazyky (jako např. java) to může být problém, ale i v takových případech by ~100 znaků mělo stačit. A odmítat něco jenom protože "je to nemoderní" je hloupé. Alespoň si najděte nejakej pořádnej důvod.
-
Neustálé šoupání nahoru/dolu vyrušuje mnohem víc, než se podívat doprava, nemusím doufám zdůrazňovat že 80 znaků zvyšuje počet řádek.
A neustálé přepínání mezi soubory vyrušuje ještě víc.
-
Hodí se to zvláště na parametry funkcí/metod a podmínky a zvyšuje to pravděpodobnost, že je funkce/metoda zobrazena celá najednou. Neustálé šoupání nahoru/dolu vyrušuje mnohem víc, než se podívat doprava, nemusím doufám zdůrazňovat že 80 znaků zvyšuje počet řádek.
Funkce/metoda se mi vždy zobrazí celá najednou i když mám krátké řádky. Šoupat nahoru/dolů nemusím, i když se mi na monitor vejde jen 30 řádek.
Omezení na 80 znaků počet řádek nijak nezvyšuje, ale dle mých zkušeností naopak snižuje.
-
Víc monitorů nepomůže, protože bych musel otáčet hlavou...
Víc monitorů, nebo jeden větší 27" a víc, je ve vývoji standard. Pokud Vám to nevyhovuje je to čistě Vás problém, dál se o tom bavit nemá smysl.
Funkce/metoda se mi vždy zobrazí celá najednou i když mám krátké řádky. Šoupat nahoru/dolů nemusím, i když se mi na monitor vejde jen 30 řádek.
Jestli se všechny tvoje funkce/metody vejdou na 30 řádek, tak diskuze s tebou na toto téma nemá smysl.
-
Funkce/metoda se mi vždy zobrazí celá najednou i když mám krátké řádky. Šoupat nahoru/dolů nemusím, i když se mi na monitor vejde jen 30 řádek.
Jestli se všechny tvoje funkce/metody vejdou na 30 řádek, tak diskuze s tebou na toto téma nemá smysl.
Všechny metody a funkce se mi vejdou do doporučovaných 20 řádek. Diskuze s tebou skutečně nemá smysl.
-
Víc monitorů nepomůže, protože bych musel otáčet hlavou...
Víc monitorů, nebo jeden větší 27" a víc, je ve vývoji standard. Pokud Vám to nevyhovuje je to čistě Vás problém, dál se o tom bavit nemá smysl.
Odvolávat se na "standard" by vám šlo... teď jenom přidat nějaký skutečný argument, proč je šířka 80 znaků špatně.
Funkce/metoda se mi vždy zobrazí celá najednou i když mám krátké řádky. Šoupat nahoru/dolů nemusím, i když se mi na monitor vejde jen 30 řádek.
Jestli se všechny tvoje funkce/metody vejdou na 30 řádek, tak diskuze s tebou na toto téma nemá smysl.
Vím že VS s tím může mít problém, ale pořádné editory podmínky a cykly skládat většinou umí.
-
Vím že VS s tím může mít problém, ale pořádné editory podmínky a cykly skládat většinou umí.
Vim sice folding umí, ale nezvykl jsem si na to. Potřebuji vidět tu metodu celou naráz a rozbalování/sbalování by mi odvádělo pozornost. Metody se mi však na obrazovku vejdou, tento problém jde tedy mimo mne.
-
Ajajajajajaj ...
-
Ajajajajajaj ...
Tohle? https://www.youtube.com/watch?v=7JNarc1KmfY (https://www.youtube.com/watch?v=7JNarc1KmfY)
-
Na C# nebo i na C++ bych doporučil toto https://www.jetbrains.com/resharper/?fromMenu. Cena je zlomková oproti Visual Studiu. Updaty a integrace nejrůznějších frameworků je svižná, co půl roku.
-
Chvála Bohu, v žádné.
+1
Používám Netbeans (Java, C++, SQL…), což je svobodný software – jeho licence mě neomezuje v tom, k jakému účelu ho budu používat. I když budu ta největší korporace na světě, stále pro mne platí stejné podmínky.
A ty seš nějakej krajně levicovej, že ti vadí opak?
Ne, spíš se řadím ke krajní pravici (v pravém slova smyslu). Od svých dodavatelů vyžaduji férové podmínky a nechci na nich být závislý – všechno co od nich mám, musí fungovat klidně i dalších padesát let, i kdyby ti dodavatelé zkrachovali a zmizeli. Totéž nabízím svým zákazníkům.
-
Chvála Bohu, v žádné.
+1
Používám Netbeans (Java, C++, SQL…), což je svobodný software – jeho licence mě neomezuje v tom, k jakému účelu ho budu používat. I když budu ta největší korporace na světě, stále pro mne platí stejné podmínky.
A ty seš nějakej krajně levicovej, že ti vadí opak?
Ne, spíš se řadím ke krajní pravici (v pravém slova smyslu). Od svých dodavatelů vyžaduji férové podmínky a nechci na nich být závislý – všechno co od nich mám, musí fungovat klidně i dalších padesát let, i kdyby ti dodavatelé zkrachovali a zmizeli. Totéž nabízím svým zákazníkům.
Tak to jsi to s tím pravicováním asi trochu přehnal a vzal jsi to dokola, protože prosazuješ docela komunistické metody :-D
-
Tak to jsi to s tím pravicováním asi trochu přehnal a vzal jsi to dokola, protože prosazuješ docela komunistické metody :-D
Kde vidíš ty komunistické metody? Používání Open Source je pravicová záležitost.
-
Tak to jsi to s tím pravicováním asi trochu přehnal a vzal jsi to dokola, protože prosazuješ docela komunistické metody :-D
Kde vidíš ty komunistické metody? Používání Open Source je pravicová záležitost.
Ale kdepak, levicová. Když zdroják patří všem, tak to je přece ideální komunizmus :-D
Znáš http://linuks.wz.cz/ ?
-
Ale kdepak, levicová. Když zdroják patří všem, tak to je přece ideální komunizmus :-D
Znáš http://linuks.wz.cz/ ?
Autor se svobodně rozhodl, že poskytne zdrojáky v takové licenci, která jim tu svobodu ochrání. Zdroják stále patří autorovi, který přidělil nabyvateli právo ho modifikovat a povinnost se připsat jako spoluautora, pokud takový zdroják předá dál. To mi nezní moc komunisticky, ale naopak velmi liberálně.
-
To mi nezní moc komunisticky, ale naopak velmi liberálně.
To mluvíte o BSD licenci?
-
To mi nezní moc komunisticky, ale naopak velmi liberálně.
To mluvíte o BSD licenci?
BSD licenci jsme tu ještě neprobrali. Směle do toho!
-
Tak to jsi to s tím pravicováním asi trochu přehnal a vzal jsi to dokola, protože prosazuješ docela komunistické metody :-D
Kde vidíš ty komunistické metody? Používání Open Source je pravicová záležitost.
Open source je právě normální levice a ideální produkt pro komunismus. Kde vidíš něco pravicového?
-
Obvykle stačí vyházet gettery a settery.
vitajte v patnastom dieli kitovho kurzu oop navrhu bez getterov, bez prikladov a bez realnych skusenosti, zato zo zadeke vytiahnutymi cislami
dnes o kitovej metrike dlzky tried
implementovat budete vo vime, s 200 riadkovym pluginom pre javu
-
To mi nezní moc komunisticky, ale naopak velmi liberálně.
Jo, jenže Castro byl také liberál, než ho USA dokopaly do chřtánu komunistům.
Pravicový je closed source: zdrojáky si nechám pro sebe, tobě propůjčím soft, a ty budeš platit a platit.
-
Pravicový je closed source: zdrojáky si nechám pro sebe, tobě propůjčím soft, a ty budeš platit a platit.
Myslíš ty tisíce bezejmenných vývojářů v softwarových fabrikách?
-
Pravicový je closed source: zdrojáky si nechám pro sebe, tobě propůjčím soft, a ty budeš platit a platit.
Myslíš ty tisíce bezejmenných vývojářů v softwarových fabrikách?
Například Micro$oft ;-)
https://web.archive.org/web/20111011140329/http://blackhole.sk/why-i-hate-microsoft-1
https://web.archive.org/web/20111011130606/http://blackhole.sk/why-i-hate-microsoft-2
https://web.archive.org/web/20111011202237/http://blackhole.sk/why-i-hate-microsoft-3
-
dnes o kitovej metrike dlzky tried
Příště bude o zavrženém "else" :)
-
Myslíš ty tisíce bezejmenných vývojářů v softwarových fabrikách?
Například Micro$oft ;-)
Takovou firmu neznám. Poněkud nevhodný nápad si dávat do názvu znak "$".
-
dnes o kitovej metrike dlzky tried
Příště bude o zavrženém "else" :)
a netreba ani if ked mate tabulky a strategy, ze?
napiste o tom blog, nazvite ho Exampless
-
Obvykle stačí vyházet gettery a settery.
vitajte v patnastom dieli kitovho kurzu oop navrhu bez getterov, bez prikladov a bez realnych skusenosti, zato zo zadeke vytiahnutymi cislami
dnes o kitovej metrike dlzky tried
implementovat budete vo vime, s 200 riadkovym pluginom pre javu
Jakoby programování bylo o editoru a o textové délce třídy. Já jsem také toho názoru že je pohodlnější použít IDE, ale VIM používám také, a to denně v závislosti na tom, co chci dělat.
Bez getterů a setterů by to asi moc u mě nešlo, chce-li člověk ještě implementovat nějaké akce na základě změny, že.
Samozřejmě je to jiná, pokud kit má třídy, které to nepotřebují, nebo je mít nesmí kvůli pravidlu o délce headeru. :)
Později, při implementaci getterů a setterů, může celý projek refaktorovat ve vimu :), které v jednom bodě jistě potřebovat začne.
To ale až mu koupí lepší tiskárnu a pravidlo o délce headeru pozbyde důvodu k existenci.
Ale samozřejme je to kitův prozíravý přístup, na který má své svobodné právo. Má na starosti veliké projekty, takže ví přece co dělá.
Berte můj příspěvek jako nadsázku. Je to tu moc hezký flame, tak proč si taky nezašpásovat!!
-K-
-
gettery a settery urobia z maleho projektu velky. +3 LoC ku kazdej premennej
-
Jakoby programování bylo o editoru a o textové délce třídy. Já jsem také toho názoru že je pohodlnější použít IDE, ale VIM používám také, a to denně v závislosti na tom, co chci dělat.
Textová délka třídy je jen užitečnou pomůckou, jak ve třídě udržet SRP.
Bez getterů a setterů by to asi moc u mě nešlo, chce-li člověk ještě implementovat nějaké akce na základě změny, že.
Kupodivu to jde. Obvykle stačí místo všech setterů použít jeden notify() a místo getterů jeden toString(). Jenže to bychom museli programovat objektově, že?
-
Myslíš ty tisíce bezejmenných vývojářů v softwarových fabrikách?
Například Micro$oft ;-)
Takovou firmu neznám. Poněkud nevhodný nápad si dávat do názvu znak "$".
A co teprve pojmenovat jí po svém penisu 8-O
-
Ano, programování je o kvalitním editoru, který pomůže udržet v kódu pořádek. Jen přehledný kód se správně pojmenovanými proměnnými/metodami a aktuálně správnou strukturou (tedy zrefaktorovaný na aktuální požadavky) má dlouhodobou hodnotu, jinak je to pouze koule na noze. Autor se mohl prsit, jak to měl krátké, ale někdo po něm jej bude proklínat. A majitel kódu platit jak mourovatý za každý další požadavek.
Do 80 sloupců se nevejde kód s popisnými názvy (ty nemají pár znaků). A nepopisné názvy (ač krátké) jsou úplně k ničemu.
To samé platí i pro linuxový kernel. Pochopit významy několikaznakových kryptických proměnných zabere spoustu času. Přitom by bývalo stačilo je pořádně pojmenovat.
Jenže na školách se učí vychytané algoritmy, mraky teorií, nic co by se v normální programátorské praxi byznys aplikací nějak zásadně využilo. Nic proti tomu, ale nesetkal jsem se s tím, že by někdo nedostal zápočet za to, že má jeho kód nedostatečně vysvětlující názvy. Přitom to je to zcela nejzásadnější - aby na tom šlo dál stavět. To se řeší až ve firmách a všichni s tím bojují (tedy kromě programátorů, těm je to fuk, však on to někdo zaplatí...). To by mělo být to nejdůležitější, co by mělo profesionálního programátora zajímat - dokáže to někdo další po mě rozvíjet dál? Není náhodou má výplata pro zadavatele dlouhodobě jen vyhozený peníz, když se tím bordelem bude muset po mě někdo prokousávat?
-
Jakoby programování bylo o editoru a o textové délce třídy. Já jsem také toho názoru že je pohodlnější použít IDE, ale VIM používám také, a to denně v závislosti na tom, co chci dělat.
Textová délka třídy je jen užitečnou pomůckou, jak ve třídě udržet SRP.
Bez getterů a setterů by to asi moc u mě nešlo, chce-li člověk ještě implementovat nějaké akce na základě změny, že.
Kupodivu to jde. Obvykle stačí místo všech setterů použít jeden notify() a místo getterů jeden toString(). Jenže to bychom museli programovat objektově, že?
A je to tady
-
Jenže na školách se učí vychytané algoritmy, mraky teorií, nic co by se v normální programátorské praxi byznys aplikací nějak zásadně využilo. Nic proti tomu, ale nesetkal jsem se s tím, že by někdo nedostal zápočet za to, že má jeho kód nedostatečně vysvětlující názvy. Přitom to je to zcela nejzásadnější - aby na tom šlo dál stavět. To se řeší až ve firmách a všichni s tím bojují (tedy kromě programátorů, těm je to fuk, však on to někdo zaplatí...). To by mělo být to nejdůležitější, co by mělo profesionálního programátora zajímat - dokáže to někdo další po mě rozvíjet dál? Není náhodou má výplata pro zadavatele dlouhodobě jen vyhozený peníz, když se tím bordelem bude muset po mě někdo prokousávat?
Tak tohle neni pravda. Moji spolužáci (ZČU) se s timhle osobně setkali, kdy jim neuznali semestrální práci, protože měli prasáckej kód. A celkově mi přišlo, že nás vedli k tomu aby jsme kód pro kalkulačku psali s ohledem na fakt, že by to někdy někdo mohl chtít předělat na operační systém.
-
Jenže na školách se učí vychytané algoritmy, mraky teorií, nic co by se v normální programátorské praxi byznys aplikací nějak zásadně využilo. Nic proti tomu, ale nesetkal jsem se s tím, že by někdo nedostal zápočet za to, že má jeho kód nedostatečně vysvětlující názvy.
Učí se tam i jiné věci, viz třeba: http://d3s.mff.cuni.cz/teaching/programming_practices/.
-
Do 80 sloupců se nevejde kód s popisnými názvy (ty nemají pár znaků). A nepopisné názvy (ač krátké) jsou úplně k ničemu.
S tím si dovolím nesouhlasit. Nikdo nedělá 80znakové popisné názvy, ale zpravidla si vystačí s 5-30 znaky. A takové výrazy se do 80 sloupců v pohodě vejdou.
To samé platí i pro linuxový kernel. Pochopit významy několikaznakových kryptických proměnných zabere spoustu času. Přitom by bývalo stačilo je pořádně pojmenovat.
Jenže na školách se učí vychytané algoritmy, mraky teorií, nic co by se v normální programátorské praxi byznys aplikací nějak zásadně využilo. Nic proti tomu, ale nesetkal jsem se s tím, že by někdo nedostal zápočet za to, že má jeho kód nedostatečně vysvětlující názvy. Přitom to je to zcela nejzásadnější - aby na tom šlo dál stavět.
S tím souhlasím. Jsem proti kryptickým názvům proměnných. Čím vzdálenější je proměnná od místa použití, tím by měl být její název popisnější.
Na druhou stranu: Proč používat vzdálené proměnné? Není lepší používat pokud možno pouze lokální a udržovat jejich názvy jednoslovní, snadno vyslovitelné (kvůli telefonu) a přitom dostatečně popisné? Vždyť v běžné třídě se nachází jen cca 2-4 atributů, v každé metodě 2-4 lokální proměnné. Copak na jejich rozlišení jsou nutná dlouhá slova typu klapkoBřinkoStroj nebo nosoČistoPlena?
-
Tak tohle neni pravda. Moji spolužáci (ZČU) se s timhle osobně setkali...
Hm, zrovna ze ZČU (KIV) byli/jsou všichni naši programátoři (já KKY, ale ani tam se nic takového samozřejmě neřešilo). Možná se to už zlepšilo, ale co když sleduji ten kód, nemám takový dojem.
-
S tím si dovolím nesouhlasit. Nikdo nedělá 80znakové popisné názvy, ale zpravidla si vystačí s 5-30 znaky. A takové výrazy se do 80 sloupců v pohodě vejdou.
Vejdou, ale vůbec ne v pohodě a přehledně, v javě bude každý druhý řádek zlomený. Nevidím důvod si znečitelnit kód úplně zbytečným omezením.
Na 5 znaků ve většině případů nedáš popisnou proměnnou, to bude akorát tak nesrozumitelná nekompletní zkratka.
-
Učí se tam i jiné věci, viz třeba: http://d3s.mff.cuni.cz/teaching/programming_practices/.
Hezké, to má přínos. A je ten předmět pro nějaký SW směr povinný?
-
v každé metodě 2-4 lokální proměnné. Copak na jejich rozlišení jsou nutná dlouhá slova typu klapkoBřinkoStroj nebo nosoČistoPlena?
Sorry, ale to je přesně ten přístup. Nejde o rozlišení proměnných od sebe, ale o jejich skutečný význam. Pak stačí špatně pojmenovaný název metody (ve stejném stylu, tedy pravidlo v takovém kódu) a neděláš nic jiného, než se snažíš pochopit, co tím vlastně autor mínil.
-
S tím si dovolím nesouhlasit. Nikdo nedělá 80znakové popisné názvy, ale zpravidla si vystačí s 5-30 znaky. A takové výrazy se do 80 sloupců v pohodě vejdou.
Vejdou, ale vůbec ne v pohodě a přehledně, v javě bude každý druhý řádek zlomený. Nevidím důvod si znečitelnit kód úplně zbytečným omezením.
Kupodivu moc těch zlomených řádek nemívám. Raději zalomím řádek než abych vkládal prázdné řádky dovnitř metod.
Na 5 znaků ve většině případů nedáš popisnou proměnnou, to bude akorát tak nesrozumitelná nekompletní zkratka.
To se mýlíš. Zkratky (kromě běžně užívaných) zásadně nepoužívám. Co máš proti názvům proměnných model, name, group, child, users, key nebo value, pokud jsou lokální? A co řídící proměnné cyklů i, j, k - ty ti také vadí?
-
Hezké, to má přínos. A je ten předmět pro nějaký SW směr povinný?
Softwarové systémy ho mají jako povinně volitelný.
-
v každé metodě 2-4 lokální proměnné. Copak na jejich rozlišení jsou nutná dlouhá slova typu klapkoBřinkoStroj nebo nosoČistoPlena?
Sorry, ale to je přesně ten přístup. Nejde o rozlišení proměnných od sebe, ale o jejich skutečný význam. Pak stačí špatně pojmenovaný název metody (ve stejném stylu, tedy pravidlo v takovém kódu) a neděláš nic jiného, než se snažíš pochopit, co tím vlastně autor mínil.
Však ten skutečný význam se dá většinou vystihnout jediným slovem. Pokud působnost takové proměnné je omezena na třídu nebo dokonce metodu, tak v tom fakt problém nevidím. Navíc taková třída bývá lépe znovupoužitelná, protože potřeba víceslovných názvů proměnných indikují porušení SRP a to tě navede na injekci těchto závislostí.
-
Jestli je to users, to vidím na první pohled - kolekce objektů User. Ale ti uživatelé jsou většinou něčím typičtí, a to je právě potřeba popsat názvem proměnné. To z žádného typu nevyčtu. Pouhé users je ve většině případů k ničemu.
Delší kód je potřeba rozpadnout do metod a většina metod má tedy jen právě jedno volání. Nerozpadám do metod primárně kvůli reuse of code, ale hlavně kvůli čitelnosti a přehlednosti. Takže v té metodě chci vědět, co přesně je to za uživatele. A pokud ji budu chtít použít později i jinde (IDE mi při vytažení metody samozřejmě rovnou nabídne další místa nahrazení, ale mluvím o pozdější době, až přijde nový požadavek), přejmenuji proměnnou na aktuálně správný název. V dobrém IDE je to jedna klávesová zkratka. A o tom tu celou dobu mluvím, je potřeba mít jasně popisné názvy. Obecné názvy jsou většinou na houby.
Již několik let refaktoruji kód řady vývojářů a velice přesně vím, o čem mluvím. Min. 80% času je refaktoring, zbytek nové featury.
Dám příklad.
Někdo žádá o účast na nějaké akci. Někdo to schvaluje.
Takže user, approver
OK, jeden vývojář použije approver ve významu schvalovatele. Jenže kdo je schvalovatel - ten kdo má schválit nebo ten kdo schválil? Přijde další a použije stejné slovo (samozřejmě field v DTO) ve významu toho, kdo zažádal jménem účastníka a rovnou mu to schválil. A po pár kolech je v tom akorát pěkný bordel, který je peklo rozmotávat. Přitom stačí přesné názvosloví:
participant, requestedBy, toBeDecidedBy, decidedBy (approved ne, protože to významově vylučuje možnost "zamítnul"). Všichni jsou to samozřejmě users.
A o tom mluvím. Na 5 znaků se nevejdeš ani náhodou.
-
participant, requestedBy, toBeDecidedBy, decidedBy (approved ne, protože to významově vylučuje možnost "zamítnul"). Všichni jsou to samozřejmě users.
A o tom mluvím. Na 5 znaků se nevejdeš ani náhodou.
Psal jsem 5-30 znaků. Do toho se vejdou všechny názvy, které jsi uvedl.
Nevím, k čemu máš to "By" na konci. Tím sémanticky vylučuješ uložení data a času podání, termínu či schválení do těchto objektů.
-
Obvykle stačí místo všech setterů použít jeden notify() a místo getterů jeden toString(). Jenže to bychom museli programovat objektově, že[/quote
priklad?
pokud nemate objekt, tak tam dejte string a pokud nemate string, tak tam nedejte nic
oop jak prase
-
;D ;D ;D ;D ;D
Po bambilionosmé ...
-
pokud nemate objekt, tak tam dejte string a pokud nemate string, tak tam nedejte nic
Vida, už ses naučil přetěžování metod!
-
priklad na triedu s notify() je opat nad vase schopnosti blabolit?
-
priklad na triedu s notify() je opat nad vase schopnosti blabolit?
Všichni přece známe Observer, ne?
-
Když nemáte getery, tak tam dejte observer.
-
Když nemáte getery, tak tam dejte observer.
Umíš také něco jiného než blábolit a provokovat? Zatím jsi toho moc nepředvedl a navíc si pleteš getter se setterem.
-
Trolling? Tohle je přece přesně otázka pro tebe.
Když nemáte nápady, tak tam dejte nesmysly!
-
Psal jsem 5-30 znaků. Do toho se vejdou všechny názvy, které jsi uvedl.
30 znaků proměnná - jak bude pak vypadat řádek s limitem 80 znaků? 30 znaků už je pěkně dlouhý popisný název. Ale proč ne, ničemu neškodí, daleko lepší než nepřesný krátký.
Nevím, k čemu máš to "By" na konci. Tím sémanticky vylučuješ uložení data a času podání, termínu či schválení do těchto objektů.
Víš, to je další problém. Pro přehledný kód (psaný v angličtině) je potřeba umět anglicky, aby se nepoužívaly matoucí či vysloveně nesprávné názvy. Každý den takové proměnné opravuji. Občas to nemá s angličtinou nic společného. To By znamená "kým". Pro ještě větší přehlednost bych to mohl doplnit o User - decidedByUser, requestedByUser. Jenže v IDE najedu na proměnnou a vidím datový typ, tudíž to User tam není nezbytné. Ale být by tam klidně mohlo.
-
takze priklad nebude?
konvenciu getterov ste nahradili patternom s rovnakym poctom riadkov?
ak ma Troll vek, vy observujete inym classom zmenu veku?
moment, to sme uz videli v inom threade a bola to debilita
-
Trolling? Tohle je přece přesně otázka pro tebe.
Když nemáte nápady, tak tam dejte nesmysly!
Proč bych se měl stále jen bránit proti trollingu?
Nepojmenovávám metody jen notify(). Jako setter (ty jsi chybně napsal getter) se moc nehodí. Zajímavé jsou i názvy metod insert(které kupodivu ukládají data do objektu), update(na modifikaci) nebo delete(copak to asi bude dělat?).
Místo getterů se mi osvědčily metody find() a search(), ale používám je málokdy, protože se řídím pravidlem: Tell, don't ask! Pro zjištění stavu objektu mi tedy obvykle stačí metoda toString() a na nic jiného se objektu neptám.
-
Nevím, k čemu máš to "By" na konci. Tím sémanticky vylučuješ uložení data a času podání, termínu či schválení do těchto objektů.
Víš, to je další problém. Pro přehledný kód (psaný v angličtině) je potřeba umět anglicky, aby se nepoužívaly matoucí či vysloveně nesprávné názvy. Každý den takové proměnné opravuji. Občas to nemá s angličtinou nic společného. To By znamená "kým". Pro ještě větší přehlednost bych to mohl doplnit o User - decidedByUser, requestedByUser. Jenže v IDE najedu na proměnnou a vidím datový typ, tudíž to User tam není nezbytné. Ale být by tam klidně mohlo.
Takže ty do objektu decidedBy vložíš uživatele i časové razítko? To pojmenování pak nedává smysl a mělo by to být jen decided, aby tam mohlo být obojí.
-
konvenciu getterov ste nahradili patternom s rovnakym poctom riadkov?
Jakých getterů? Psal jsem o náhradě setteru, tak si to pořád nepleť!
Neříkám objektu "Tohle si nastav takhle", ale "Tohle se stalo, udělej si s tím, co chceš".
-
Neexistuje do jednoho názvu vložit dva významy. Ano, i s takovými situacemi se bohužel setkávám - viz ten approver.
Bude-li potřeba uložit datum, proměnná se přejmenuje na tu variantu s ...ByUser. Jo, bylo by lepší to tam dát rovnou, ale projekt naštěstí nemusí držet fixní API (verze), vývojáři jedou nad stejným kódem v gitu. Obrovská výhoda v udržování projektu, nemít svázané ruce starými chybami (MS by mohl vyprávět...).
Nicméně z těch datumových variant dává smysl jen toBeDecidedByDate. Ani requestedByDate ani decidedByDate není anglicky. To by bylo requestedOnDate a decidedOnDate. Mohlo by se vyskytovat i toBeRequestedByDate, ale ne requestedByDate. Jsme zase zpět u používání angličtiny v přesných významech...
-
Bude-li potřeba uložit datum, proměnná se přejmenuje na tu variantu s ...ByUser.
Když do toho objektu chci uložit uživatele i datum, tak přece neudělám dva objekty approvedByUser a approvedByDate, ale použiji jen jeden objekt a nazvu ho approved, ve kterém bude user i datum, protože spolu tvoří relaci.
-
V tomto případě není podstatné, zda do DTO žádosti dám usera a date v samostném DTO, nebo napřímo. Podstatné pro tuto diskusi je názvosloví. Zrovna approved je zcela špatně, to je boolean a ne objekt nesoucí údaje o schválení. Když už tak approval. Může mít např. fieldy byUser a onDate. Pouhé user a date by bylo opět nepřesné, někdo může "user" pochopit jako "komu schváleno" a date třeba i to "do kdy" (nepravděpodobně).
Prostě jednoslovné názvy proměnných jsou velice často nepřesné a není žádný důvod se jimi omezovat.
Myslím, že jsem řekl jasně, o co mi jde. Další diskuse na tohle téma už asi nedává smysl.
-
Jakých getterů? Psal jsem o náhradě setteru, tak si to pořád nepleť
ok a ten observer nastavite ako?
zmeny atributov nastavite ako na dto?
ten tostring je miesto gettera co za komediu? parsujete potom stav objektu zo stringu? priklad?
vy musite byt na projekte fakt sam ako Babica:-) mate vlastne patterny, konvencie a divaci vase diela zrat nebudu
-
ten tostring je miesto gettera co za komediu? parsujete potom stav objektu zo stringu? priklad?
Proč bych měl výstup metody toString() parsovat? Vždyť to je finální výsledek, který třeba pošleš na výstup. Dej sem příklad, kdy k něčemu potřebuješ getter.
-
Máme dejme tomu objekt který obsahuje jméno člověka, jeho záliby, jeho věk a třeba jeho demenci. Chceme někam vypsat pouze jeho jméno a demenci, řekni mi jak to zvládneš bez getteru?
-
Máme dejme tomu objekt který obsahuje jméno člověka, jeho záliby, jeho věk a třeba jeho demenci. Chceme někam vypsat pouze jeho jméno a demenci, řekni mi jak to zvládneš bez getteru?
udělal bych to publik
ale já bych to někomu spíš zadal a bylo by vystaráno 8)
-
Jakoby programování bylo o editoru a o textové délce třídy. Já jsem také toho názoru že je pohodlnější použít IDE, ale VIM používám také, a to denně v závislosti na tom, co chci dělat.
Textová délka třídy je jen užitečnou pomůckou, jak ve třídě udržet SRP.
Bez getterů a setterů by to asi moc u mě nešlo, chce-li člověk ještě implementovat nějaké akce na základě změny, že.
Kupodivu to jde. Obvykle stačí místo všech setterů použít jeden notify() a místo getterů jeden toString(). Jenže to bychom museli programovat objektově, že?
Ach bože můj.
Ale nic...jak jsem říkal. Dělej si to jak chceš. Tvůj boj. A nesmrtelný přesvědčení o vlastní nejlepšíí metodě. :)
Mě se tady jen líbí ten flame. ;)
-
Máme dejme tomu objekt který obsahuje jméno člověka, jeho záliby, jeho věk a třeba jeho demenci. Chceme někam vypsat pouze jeho jméno a demenci, řekni mi jak to zvládneš bez getteru?
Pokud ostatní atributy nepotřebuji, tak je v tom objektu ani nemusím mít. Budu tam mít jen jméno a demenci, resp. metoda toString() bude vypisovat pouze jméno a demenci. Pokud je motoda toString() obsazena úplnou prezentací objektu, mohu napsat další prezenteční metodu, která poskytne jméno a demenci v požadovaném formátu. Možná to označíš za getter, ale vzhledem k tomu, že to nepoužívám, tak je to jedno.
Také bych si mohl nechat poslat všechny atributy messengerem a z nich si vybrat, ale proč bych to dělal? Okolní objekty nemají co čumět na atributy objektu ani prostřednictvím getterů.
-
udělal bych to publik
Nezapomeň, že chceme udržet zapouzdření objektu. Takže žádný public, getter ani setter.
-
Ach bože můj.
Ale nic...jak jsem říkal. Dělej si to jak chceš. Tvůj boj. A nesmrtelný přesvědčení o vlastní nejlepšíí metodě. :)
Mě se tady jen líbí ten flame. ;)
Je lepší mít vlastní (třeba i mizerný) názor, než nemít žádný. Zatím tady vidím jen papouškování, že bez getterů a setterů to nejde, sem-tam nějaký povzdech, výsměch, přirovnávání k Babicovi, ale argumentů žalostně málo. Tedy až na dustina, jehož názory mi dávají smysl.
-
Ach bože můj.
Ale nic...jak jsem říkal. Dělej si to jak chceš. Tvůj boj. A nesmrtelný přesvědčení o vlastní nejlepšíí metodě. :)
Mě se tady jen líbí ten flame. ;)
Je lepší mít vlastní (třeba i mizerný) názor, než nemít žádný. Zatím tady vidím jen papouškování, že bez getterů a setterů to nejde, sem-tam nějaký povzdech, výsměch, přirovnávání k Babicovi, ale argumentů žalostně málo. Tedy až na dustina, jehož názory mi dávají smysl.
Podstata mého povzdechu je v tom, že nějak nechápeš hyperbolu v mém příspěvku.
To, že raději než gettery raději vracíš výsledek je dobře, pokud to je možné. Což ale nemusí být vždy.
Například ta třída nemusí mít ponětí o tom jak ten finální výsledek má vypadat... může to pak skončit že máš tisíc (pozor to byla nadsázka!!) různých formátovacích metod... takže můžeš dojít zpětně k tomu getteru, případně k fundanentální otázce jestli forma toho výstupu je skutečně starostí té třídy a né jiné, co výstupu skutečně zobrazuje.
Ale jak říkám, je mi úplně jedno jak píšeš své projekty a jaké máš konvence. Protože všechny jsou v zásadě správné pokud se dodržují.
-K-
-
Dej sem příklad, kdy k něčemu potřebuješ getter.[/q quote]
adresar ma subory ktore chcete renderovat do zoznamu alebo tabulky. u vas urobite 2 metody na adresari kde a vydrbnete dvakrat html.
so long mvc
k nastavovaniu observera ste sa nevyjadrili, nesedi do kramu?
vy ste Babicoid preto ze ste neukazali ani riadok kodu co je pri programovani dosti podstatna zavada ked chcete prisahat na vase gerojske rady do vyvoja
-
Zatím tady vidím jen papouškování, že bez getterů a setterů to nejde
class Papousek {
pablik void toString() {
return "uz ste ukazali na realnom kode ze to ide?";
}}
-
Kit je troll, nič viac nič menej. Nikdy sem nedá reálnu ukážku, lebo ani sám nevie o čom točí.
-
ta debata tu uz raz bola, kit ju zavrel ze scala neni jak php ked zacalo smrdiet pod zadeke
hlavne ked zacal smrdiet kod co nebol ani oop ani srp ani nic podobne co tvrdil
http://forum.root.cz/index.php?topic=10217.msg114591#msg114591
-
Jakých getterů? Psal jsem o náhradě setteru, tak si to pořád nepleť
ok a ten observer nastavite ako?
zmeny atributov nastavite ako na dto?
ten tostring je miesto gettera co za komediu? parsujete potom stav objektu zo stringu? priklad?
vy musite byt na projekte fakt sam ako Babica:-) mate vlastne patterny, konvencie a divaci vase diela zrat nebudu
Observer takto neda, ale mozno to obhaji tym, ze to nepotrebuje. GUI asi nerobi, lebo tam je default binding tak trochu problem bez getterov a setterov.
Zmena atributov je v 90% zlo, lebo to znamena mutable object state. To sa potom clovek uklonuje k smrti alebo ma nieco tazko udrziavatelne.
V suvislosti so zmenou atributov preto casto nedava zmysel setter. Getter je bud nahraditelny public final fieldami alebo (lepsie) tak, ze sa druhemu objektu nepreda objekt s getterami, ale rovno tie data.
-
To co je za moda s tymi immutable objektami? Zase si niekto nieco vykusol z kontextu, ci kde sa to vzalo?
-
To co je za moda s tymi immutable objektami? Zase si niekto nieco vykusol z kontextu, ci kde sa to vzalo?
- netreba riesit synchronizaciu
- staci jedna instancia konkretnej reprezentacie pre celu aplikaciu
- je to bezpecne davat to aj do API alebo neznamym programatorom
Hlavne prvy bod vedie v dnesnej dobe, ked sa riesi paralelizacia.
-
s observerom zacal kit tym ze g/s netreba lebo ma observery :-)
vestit z kavove sedliny jeho postov nebudem. vychadzam z predpokladu ze kit ide jednomuzny php projekt
s immutable mozete programovat v pohode ale zase bezna java / php vec je o dto mvc a immutable styl je inde
avsak spring vam da immutability ako byproduct. beany su immutable po vykonani dependency injection a co sa meni su dto a.k.a data pre entity v db. cez settery / konstruktor wirujete spolupracovnikov, g/s sa prejavia primarne v dto
synch neriesite, beany su teda tradicne threadsafe a defaultne singletony
samozrejme mozete ist hardcore fp styl a ist skalovat akka stylom :-)
-
Kdyz jako tema vidim VS tak se zeptam:
Byl by nekdo ochoten zkompilovat opensource SW pro Win a nekam to vystavit? Ja jsem to nikdy nedelal a ani nemam VS. Udajne jsou tam pripravene 'projekty' pro VS2003 a VS2010, pry v podstate jen staci kliknout na compile...... Kdyztak prosim mailnete na: lotkar840 at gmail dot com
-
- netreba riesit synchronizaciu
- staci jedna instancia konkretnej reprezentacie pre celu aplikaciu
- je to bezpecne davat to aj do API alebo neznamym programatorom
Hlavne prvy bod vedie v dnesnej dobe, ked sa riesi paralelizacia.
Ja viem na co to je, ale 90% pripadov? Kolko % javistov niekedy riesila synchronizaciu, ked vacsina aj tak lepi servlety v springu, alebo apky v androide? Je to uzitocne, ale iba na velmi specificke pripady. Nie je to ani prirodzene v zmysle oop. Zober si instanciu cloveka. Chces povedat, ze pribral. Vytvoris kvoli tomu noveho cloveka s inou vahou?
-
Vlastne som sa pomylil, toto sa tyka javy (mam plnu hlavu prace)..ale myslim, ze o .nete plati to iste.
-
Pokud ostatní atributy nepotřebuji, tak je v tom objektu ani nemusím mít. Budu tam mít jen jméno a demenci, resp. metoda toString() bude vypisovat pouze jméno a demenci. Pokud je motoda toString() obsazena úplnou prezentací objektu, mohu napsat další prezenteční metodu, která poskytne jméno a demenci v požadovaném formátu. Možná to označíš za getter, ale vzhledem k tomu, že to nepoužívám, tak je to jedno.
Přijde mi poněkud úsměvné, že zrovna osoba, která se tak vehementně zaštiťuje čistotou kódu, návrhovými vzory, principy, mnohdy dovedenými až do absurdna tu najednou vyprodukuje obhajobu svého postupu, kterou lze interpretovat takto:
Bytostně nenávidím a tedy nepoužívám gettery. Místo toho raději své business/dto/doplň_si_sám třídy zaneřádím balastem, který do jmenované vrstvy vůbec nepatří - totiž prezentační logikou. Je to sice nepružné, neelegantní, omezující a obtížně použitelné, ale nandal jsem to těm zpropadeným getterům. Tyhlety jazykové, regionální a uživatelem definovatelné prezentační preference každého jenom otravují. Jedna textová reprezentace třídy musí stačit všem, definuju já. Za ideály jsem připraven přinést oběti.
S tímto tvým přístupem musí být lahůdka řešit tabulková data, MVC, MVVM, WPF data binding, data mappery, entity, ORM atd.
Příklad z nejtriviálnějších: třída BusinessCard. Bez getterů či jiných read-only přístupových metod ke strukturovaným datům. Šílenost. Řekněme, že v uvedené třídě je mimo jiné použit atribut popisující pohlaví pomocí interního kódu. Koncovému uživateli jej v metodě ToString naformátuješ jak? Kdo a jak rozhodne o tom co je to požadovaný formát a jak se to nebohá třída implementující koncověuživatelskopřívětivý ToString dozví, a co je jí vlastně po tom?
Ad VIM vs VS. Mám jisté obavy, že ve VIMu vůbec nepůjde zrealizovat spousta věcí, které jsou ve VS samozřejmé a každodenní rutinou. Vývoj UI, generované třídy, např. entity framework, WS klient, rozumná práce se solution. Všechny ty graficko-interaktivní záležitosti, v jistých kruzích nepopulární zato efektivní "klikátka".
-
Doplněk: a s LINQem si tím pádem taky moc legrace neužiješ ;D
-
Pokud ostatní atributy nepotřebuji, tak je v tom objektu ani nemusím mít. Budu tam mít jen jméno a demenci, resp. metoda toString() bude vypisovat pouze jméno a demenci. Pokud je motoda toString() obsazena úplnou prezentací objektu, mohu napsat další prezenteční metodu, která poskytne jméno a demenci v požadovaném formátu. Možná to označíš za getter, ale vzhledem k tomu, že to nepoužívám, tak je to jedno.
Přijde mi poněkud úsměvné, že zrovna osoba, která se tak vehementně zaštiťuje čistotou kódu, návrhovými vzory, principy, mnohdy dovedenými až do absurdna tu najednou vyprodukuje obhajobu svého postupu, kterou lze interpretovat takto:
Bytostně nenávidím a tedy nepoužívám gettery. Místo toho raději své business/dto/doplň_si_sám třídy zaneřádím balastem, který do jmenované vrstvy vůbec nepatří - totiž prezentační logikou. Je to sice nepružné, neelegantní, omezující a obtížně použitelné, ale nandal jsem to těm zpropadeným getterům. Tyhlety jazykové, regionální a uživatelem definovatelné prezentační preference každého jenom otravují. Jedna textová reprezentace třídy musí stačit všem, definuju já. Za ideály jsem připraven přinést oběti.
S tímto tvým přístupem musí být lahůdka řešit tabulková data, MVC, MVVM, WPF data binding, data mappery, entity, ORM atd.
Příklad z nejtriviálnějších: třída BusinessCard. Bez getterů či jiných read-only přístupových metod ke strukturovaným datům. Šílenost. Řekněme, že v uvedené třídě je mimo jiné použit atribut popisující pohlaví pomocí interního kódu. Koncovému uživateli jej v metodě ToString naformátuješ jak? Kdo a jak rozhodne o tom co je to požadovaný formát a jak se to nebohá třída implementující koncověuživatelskopřívětivý ToString dozví, a co je jí vlastně po tom?
Ad VIM vs VS. Mám jisté obavy, že ve VIMu vůbec nepůjde zrealizovat spousta věcí, které jsou ve VS samozřejmé a každodenní rutinou. Vývoj UI, generované třídy, např. entity framework, WS klient, rozumná práce se solution. Všechny ty graficko-interaktivní záležitosti, v jistých kruzích nepopulární zato efektivní "klikátka".
Kita si nevsimej, on vetsinou jenom takhle bezhlave placa.
-
Ad VIM vs VS. Mám jisté obavy, že ve VIMu vůbec nepůjde zrealizovat spousta věcí, které jsou ve VS samozřejmé a každodenní rutinou. Vývoj UI, generované třídy, např. entity framework, WS klient, rozumná práce se solution. Všechny ty graficko-interaktivní záležitosti, v jistých kruzích nepopulární zato efektivní "klikátka".
Tak "unixový" přístup je určitě značně rozdílný, takže oddělit vim od zbytku prostředí dost dobře nejde. Ona se klikátka ve většině případů (mezi něž návrh GUI asi nepatří) dají nahradit prográmkem/skriptem/doplňkem. Samozřejmě je otázka, jestli existuje dostatečné nástroje pro C#... ale v něm já moc nedělám.
-
Chvála Bohu, v žádné.
+1
Používám Netbeans (Java, C++, SQL…), což je svobodný software – jeho licence mě neomezuje v tom, k jakému účelu ho budu používat. I když budu ta největší korporace na světě, stále pro mne platí stejné podmínky.
Coz nemeni nic na tom, ze na C# je lepsi VS.
Probůh, k čemu C#? To bych už rovnou mohl používat jako OS windows ;D
:o
Windows jako OS?
NEMOHL
U nás jsme měli programátora který dřív dělal v linux/ruby a přešel na widle/VS, pár měsíců potom začal chlastat a skončil. Bacha na to i takové případy jsou.
-
U nás jsme měli programátora který dřív dělal v linux/ruby a přešel na widle/VS, pár měsíců potom začal chlastat a skončil. Bacha na to i takové případy jsou.
Práce se Visual Studiu není pro mamánky a slabochy. Jen pro správné chlapy.
-
- netreba riesit synchronizaciu
- staci jedna instancia konkretnej reprezentacie pre celu aplikaciu
- je to bezpecne davat to aj do API alebo neznamym programatorom
Hlavne prvy bod vedie v dnesnej dobe, ked sa riesi paralelizacia.
Immutable je nové falešné náboženství slibující vyřešit všechny vaše problémy, podobně jako před lety náboženství OOP, jenže opět nevyřeší.
Immutable se náramně hodí na read-only sdílené data. V momentě kdy je třeba sdílené data modifikovat, je immutable ještě horší než tradiční synchronizace, při výměně instance za novou verzi vzniká špatně debugovatelný tradiční problém read-modify-write.
Na problém s paralelismem a API není immutable nutné, stejný efekt má prostá kopie objektu.
-
Bože, to je zase debata. Kde jsou ty časy, kdy se k počítačům a programování dostali jen lidi s IQ > 130...
-
- netreba riesit synchronizaciu
- staci jedna instancia konkretnej reprezentacie pre celu aplikaciu
- je to bezpecne davat to aj do API alebo neznamym programatorom
Hlavne prvy bod vedie v dnesnej dobe, ked sa riesi paralelizacia.
Immutable je nové falešné náboženství slibující vyřešit všechny vaše problémy, podobně jako před lety náboženství OOP, jenže opět nevyřeší.
Suhlas; ze vyriesi vsetky problemy som sa ani nesnazil tvrdit.
Immutable se náramně hodí na read-only sdílené data. V momentě kdy je třeba sdílené data modifikovat, je immutable ještě horší než tradiční synchronizace, při výměně instance za novou verzi vzniká špatně debugovatelný tradiční problém read-modify-write.
Ako casto je treba mat modifikovatelne zdielane data mimo I/O? Teda v Jave a Swingu so swingbindingom to treba je, ale Haskellisti so svojimi pure funkciami by skor nesuhlasili.
Na problém s paralelismem a API není immutable nutné, stejný efekt má prostá kopie objektu.
To som pisal v minulom prispevku, ze sa uklonujes k smrti. Tak je navrhnuty aj "vyborny" java.util.Date. Ked chcem API s datumami a nechcem si tahat ako zavislost Joda time, tak musim kazdy Date "z vonku" naklonovat. Rovnako to plati aj u Date posielaneho von, ak je to sucast mojho stavu.
Je preto Date nejaky lepsi ohladne problemov s read-modify-write? Ja si myslim, ze nie, dokonca je aj preto horsi.
- netreba riesit synchronizaciu
- staci jedna instancia konkretnej reprezentacie pre celu aplikaciu
- je to bezpecne davat to aj do API alebo neznamym programatorom
Hlavne prvy bod vedie v dnesnej dobe, ked sa riesi paralelizacia.
Ja viem na co to je, ale 90% pripadov? Kolko % javistov niekedy riesila synchronizaciu, ked vacsina aj tak lepi servlety v springu, alebo apky v androide? Je to uzitocne, ale iba na velmi specificke pripady. Nie je to ani prirodzene v zmysle oop. Zober si instanciu cloveka. Chces povedat, ze pribral. Vytvoris kvoli tomu noveho cloveka s inou vahou?
Aj appky v Androide miestami potrebuju synchronizaciu. Preto si myslim, ze ju riesil kazdy, aj ked nie kazdy si to uvedomil - niekto nasekal race conditiony.
V Jave sa bezne novy clovek kvoli zmene nevytvori; v inych programovacich jazykoch ano. Myslim, ze je len otazkou casu, co sa aj Java posunie k niecomu funkcionalnejsiemu a bude sa tam bezne vytvarat iny clovek.
-
Ako casto je treba mat modifikovatelne zdielane data mimo I/O?
Modifikovatelná sdílená data byla hlavní příčinou vzniku Immutable, hlavně neštěstí způsobené nekvalifikovanými programátory při přechodu na multithreading.
Ked chcem API s datumami ... tak musim kazdy Date ... naklonovat.
Proto ho s Immutable variantou Date naklonuješ pokaždé, ne jenom když si o to někdo požádá přes API ;)
-
Modifikovatelná sdílená data byla hlavní příčinou vzniku Immutable, hlavně neštěstí způsobené nekvalifikovanými programátory při přechodu na multithreading.
Neviem, ci uz niekto rozmyslal nad multithreadingom v case vzniku jazykov ako Prolog. Z toho pristupu (a neskor z Haskellu) podla mna pochadza snaha mat immutable.
Ked chcem API s datumami ... tak musim kazdy Date ... naklonovat.
Proto ho s Immutable variantou Date naklonuješ pokaždé, ne jenom když si o to někdo požádá přes API ;)
Preco by som to robil? Proste kludne pouzijem jeho instanciu (setter) alebo moju instanciu (getter). Je to vidiet na Stringoch, ktore su z principu immutable - este som nevidel program, ktory by pri vracani hodnoty ulozenej v Stringu volal nieco ako string.clone() - ani neviem, na co by to bolo dobre. Pri java.util.Date je to skoro povinnost.
-
Neviem, ci uz niekto rozmyslal nad multithreadingom v case vzniku jazykov ako Prolog.
Před multithreadingem bylo v Javě s immutable ticho po pěšině.
Je to vidiet na Stringoch, ktore su z principu immutable
Ano je to tam krásně vidět, při změně jednoho znaku musíš celý string okopírovat a to je prakticky to samé jako klonování.
-
a preto sa na interview hovori ze kto concatenuje stringy cez + je zver a ma pouzivat stringbuilder
-
Nie je zver, StringBuilder sa oplati az pri vacsich mnozstvach stringov. Rezia okolo nieco trva.
-
Je to vidiet na Stringoch, ktore su z principu immutable
Ano je to tam krásně vidět, při změně jednoho znaku musíš celý string okopírovat a to je prakticky to samé jako klonování.
Je rozdiel zmena a predavanie niekomu inemu. Zmeny sa deju vynimocne, predavanie je tu skoro stale.
Nie je zver, StringBuilder sa oplati az pri vacsich mnozstvach stringov. Rezia okolo nieco trva.
Co myslis, ako funguje to +?
Ked su to staticke stringy v kode:
String abc = "neco"+
"dlouhe";
tak tam si to spoji kompilator sam.
Inde su nasledujuce dve volania ekvivalentne:
String abc = a + b + c;
a
String abc = new StringBuffer(a).append(b).append(c).toString();
StringBuffer/StringBuilder je dobry v pripade, ze spajas viac Stringov postupne a kompilator z toho StringBufferu musi vzdy spravit String. Tam sa to kopiruje a je to pomale. Pri jednorazovom spojeni takto rozpisany StringBuffer iba komplikuje citanie programatorom.
-
Je rozdiel zmena a predavanie niekomu inemu. Zmeny sa deju vynimocne, predavanie je tu skoro stale.
Pokud máš objekt kde změně dochází výjimečně, pak rozdíl asi nepochopíš.
kto concatenuje stringy cez + je zver a ma pouzivat stringbuilder
Přiměřený počet "+" je optimalizován překladačem na StringBuilder automaticky :)
-
Je rozdiel zmena a predavanie niekomu inemu. Zmeny sa deju vynimocne, predavanie je tu skoro stale.
Pokud máš objekt kde změně dochází výjimečně, pak rozdíl asi nepochopíš.
Podla mna je taky kazdy objekt. Vynimocne myslim v porovnani s predavanim objektu.
Zmena atributov nastane u objektu raz po nejakej akcii od uzivatela alebo po meniacom kroku v algoritme, potom dlho nic. Volanie s objektom ako parametrom nastava pri skoro kazdej praci s objektom a to niekedy aj viackrat, lebo objekt moze putovat cez viacero funkcii.
-
k stringbuilderu to vyzera tak ze tie optimalizacie su dost nepredvidatelne
http://www.code-thrill.com/2012/08/stringbuilder-optimizations-demystified.html
better safe than sorry ako vravi clanok
a premature optimization, evil, knuth atd
z toho vyplyva ze to v jave nie je stymi immutable take jasne
-
k stringbuilderu to vyzera tak ze tie optimalizacie su dost nepredvidatelne
http://www.code-thrill.com/2012/08/stringbuilder-optimizations-demystified.html
Ad Myth 1.1 - spojenie 2 Stringov je tusim aj v JLS. Necakal som, ze to optimalizuje aj spojenie intu so Stringom. Aj keby to neoptimalizoval, tak sa to vykona raz za beh programu a programator by to nenapisal lepsie = pohoda.
Ad Myth 1.2 - to som pisal pri a+b+c, ze sa tam aj tak pouzije StringBuilder
Ad Myth 2 a Myth 3 - kto by cakal, ze sa to spravi vsetko naraz? Toto bolo ocakavane, lebo v druhom kroku sa vyzaduje String "123456", tak ho on musi vyrobit. Podobne v ostatnych krokoch. Nebude vyrabat StringBuilder, ked od neho chcem String
better safe than sorry ako vravi clanok
Clovek by si mal uvedomit, co od programu chce. Java nie je jasnovidec, ale ked ma presne dane operacie, tak ich splni. Teda jednorazove spojenie Stringov pomocou +, ktore sa priradi vo finalnej podobe do Stringu je prehladnejsie ako StringBuilder.
Ak to potrebuje priradit medzikroky do Stringov, tak sa medzikrok proste prevedie na String a tam uz by som ja pouzil StringBuilder.
z toho vyplyva ze to v jave nie je stymi immutable take jasne
Toto je vec Stringov. Konkretne to spojenie viac statickych Stringov pomocou + je dokonca vec JLS, takze sa to ani zdaleka netyka vsetkych immutable.
-
Pokud tvůj "zadavatel úkolů" je větší firma, máš s community edition smůlu, tu můžeš komerčně použít pro vývoj menších retailových aplikací, ne na zakázku pro velkého objednatele. Ale licenční podmínky používání produktů MS zjistíš nejlíp na MS, tady není vhodné místo.
Co přesně ti ve verzi Express chybí?
V 2010 Express začínám narážet, že nemohu použít Entity Framework v 5.0, který bych se chtěl naučit.
Ještě jsem našel Visual Studio 2013 Express for Windows Desktop, který se také zdá být zdarma.
Pro zaměstnavatele bych vyvíjel v 2010 a pro svoje účely bych používal zmíněný 2013.
Děkuji
-
2013 Community edice je zdarma, obsahuje všechny vlastnosti Prof. edice. Je použitelná i komerčně - pro jednotlivce a malé týmy (tuším do 5 lidí). Rozhodně to není crippleware typu jiných vývojových nástrojů, kde třeba v nejslabší (byť těžce placené) edici se nelze vyvíjet programy pracující s databází.
Pokud někoho zaměstnavatel nutí vyvíjet v Express edici, která neumí skoro nic, je to na vážný pohovor. Buď o tom, zda-li se mu ten vývoj softwaru skutečně tolik nevyplácí, aby do toho neinvestoval peníze za alespoň Profi+ReSharper, nebo je na na místě zvážit jiného zaměstnavatele. Express edice se hodí opravdu jenom pro výuku či pro jednoduché projekty.
Ad "pro zaměstnavatele bych vyvíjel v 2010" ... proč? V mnoha případech k tomu důvod není...
-
Zaměstnavatel opravdu vyvíjí v placené 2010 prof. Mně ale zatím tento software dodán nebyl(licence).
Tým je větší - Community edition použít nesmím.
Jsem zaměstnaný na DPP.
Teď opravdu potřebuju 2013 Express for Desktop právě kvůli samostudiu, ale na NB mám vše legální a nechtěl bych se spálit.
Ono psát ve větší verzi a pak projekt konvertovat před nahrátím na github je taky režie.
S pozdravem a díky
-
2013 Community edice je zdarma, obsahuje všechny vlastnosti Prof. edice. Je použitelná i komerčně - pro jednotlivce a malé týmy (tuším do 5 lidí). Rozhodně to není crippleware typu jiných vývojových nástrojů, kde třeba v nejslabší (byť těžce placené) edici se nelze vyvíjet programy pracující s databází.
Krome toho ze neumoznuje spouste pluginy tak napriklad Express verze neosahuje soubor "C:\Program Files (x86)\Common Files\Merge
Modules\microsoft_vc90_CRT_x86.msm" (merge module). Takze i kdyz pouzijes WIX na generovani .msi baliku, tak stejne nemuzes rozume pribalit runtime knihovny ke svoji aplikaci. Pouzitelne to rozhodne je, ale obcas to dokaze claveka zradit, kdyz to nejmene ceka.
U verze 2010 byly bugy, ktery se daly spravit fixpackem, ktery ale nesel aplikovat na Expres verzi. To bylo horsi. Nastesti ale slo ten fix stahnout, rozbalit a konkretni DDLka nahradit rucne.
-
Takže jen jednoduchá otázka, smím na počítači, který je určen ke komerčním účelům, používat VS2013 Express for Windows Desktop?
Díky
-
Jo.
-
A community edition taky, pokud to licence dovoluje (je tam omezen počet členů vývojového týmu).
Community edice podporuje pluginy, takže např. ReSharper funguje. Ty merge moduly jsem ale nezkoumal nikde - vědomě jsem to nikdy nepoužil a to už jsem si sáhl i na deployment komerčních desktop aplikací.