Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: MAXimus 10. 05. 2016, 22:08:59
-
Ak mozem poprosit, bol by som rad ak by sa k tejto teme vyjadrili hlavne programatori Java Enterprise ktory vedia ako to realne funguje v praxi.
Som studentom IT na vysokej skole a bavi ma programovanie v Java ... realne zvazujem, zeby som sa po skole venoval vyvoju webovych aplikacii v tomto jazyku, no niesom velky kamarat s linuxom. Preto by ma zaujimalo ci v reale vyuziva java vylucne s linuxom a ake su moje sance najst seriozny job v nejakej vacsej korporacii za predpokladu, ze budem v jave fakt dobry, no nebudem holdovat linuxu. Dakujem
-
Nemusis holdovat linuxu, ale praca nie je iba zabava a keby som s tebou robil pohovor, asi by som sa ta opytal preco ten linux nevies? Potom by som mal pochyby, lebo mozes dostat rozne projekty a nie vsetky budu priatelske a zabavne.. K tomu linuxu, zavisi od projektu. Ja som nezazil, ze by sa vyvijalo na linuxe. Normalne programujes v eclipse, nejaky ten tomcat alebo aplikacny server bezia aj na windows a prave vyhoda javy je v platformovej nezavislosti (aspon sa snazi byt). Zakladne prikazy (napr na restart servera) by si mal ovladat, ale ak chces byt programator, tak by si nemal mat problem sa to naucit. Cize nemusis byt linuxovy hacker, ale mal by si vediet, kde je sever.. (co je to cron, ze su nejake init scripty atd)
K tej java enterprise..vela projektov sa robi aj v springu. Ak povies ze vies java ee a spring, tak tvoje sance najst seriozny job su dost vysoke.
-
andy to povedal vsetko. nemyslim si ze seriozny zamestnavatel by ta nezobral pretoze nevies s linuxom, stale sa na linux pozera ako na plus a nie na nutnost
ja to mam presne naopak a asi trochu tazsiu vychodiskovu poziciu, odmietam pracovat s windowsom a viac menej som sa preto s terajsim zamestnavatelom rozlucil pretoze mi to chcel rozkazat a to ja nemienim tolerovat
-
kazdopadne, ako iste vies tak sa na javu nabaluje vela nastrojov ako gradle, maven, ant ... nie je na skodu aj nejaky ten docker, rozne aplikacne servery a podobne a viac menej sa nevyhnes tomu ze to budes musiet pouzivat.
z toho co som videl ako to ludia pouzivaju na windowse to nie je extra vyhra, sami na to nadavaju ze akonahle chces robit vo windowse nieco konzoloidne tak to je ciste utrpenie, preto minimalne by som instaloval git-bash.
uprimne si neviem velmi predstavit, ze by niekto totalne vsetko robil z IDE, ak dam ruku na srdce tak z 13tich kolegov, dvaja pouzivaju windows, dvaja mac, ostatni linux a dvaja testeri maju windows tiez takze by som povedal ze k tomu linuxu nejako postupom casu asi doiterujes aj tak :)
-
A v cem presne je problem naucit se Linux tak, aby o nem clovek vedel par zakladnich veci? Ne kazdy musi umet programovat jadro, navic Linux uz davno neni akorat nejake strasne CLI na cernem displayi.
-
Dakujem za odpovede :) no budem sa musiet nejak s tym linuxom lepsie oboznamit a mozno nakoniec ze to nebude az taky problem :)
A nepovedal by som ze snim mam vyslovene problem ... no som nan zvyknuty a pracuje sa mi snim dobre, zatial som na nom nemal problem ktory by sa nedal vyriesit. Popravde trocha zvazujem aj ze sa dam na .NET, prave kvoli windowsu ... 100 ludi 100 chuti
-
S tym novym ASP.NET Core podla mna bude .net este ziadanejsi takze to asi tiez nebude zla volba :)
-
Linux pro programovani v jave neni nutny. U nas v tymu jsem jedinej, kdo ma na desktopu linux. Ostatni pouzivaji windows i kdyz je nas runtime linux.
Jsou drobnosti, ktere pak nejsou prijemne. e.g. windows file timestamp je v milisekundach ale linux file timestamp je v sekundach.
Toto muze zpusobit problemy, pokud se timestamp porovnava s timestamp ulozenou v databazi ... atp.
Osobne se mi lepe programuje v linuxu, ale chapu, ze to neni pro kazdeho. Vyhoda je, ze kdyz se pak musim pripojit k testovacim servcerum nebo jeste hur k produkci, tak jsem jako doma a nemusim se soustredit na "boj" se systemem, ale na reseni problemu.
Ak mozem poprosit, bol by som rad ak by sa k tejto teme vyjadrili hlavne programatori Java Enterprise ktory vedia ako to realne funguje v praxi.
Som studentom IT na vysokej skole a bavi ma programovanie v Java ... realne zvazujem, zeby som sa po skole venoval vyvoju webovych aplikacii v tomto jazyku, no niesom velky kamarat s linuxom. Preto by ma zaujimalo ci v reale vyuziva java vylucne s linuxom a ake su moje sance najst seriozny job v nejakej vacsej korporacii za predpokladu, ze budem v jave fakt dobry, no nebudem holdovat linuxu. Dakujem
-
je uplne bezne ze sa java developuje na windowse a produkcia bezi na linuxe
-
Nekde se jede na Win s deployem na Linux. Ale poptavde receno - kdyz uz se ti nechce mit Linux na desktopu, tak snad radeji jit s davem a poridit si Maca. To je ted asi nejcastejsi varianta (Mac jako stanice, Linux jako server).
-
Vetsina Java programatoru pouziva Windows a deployment dela na Linuxu. Kazdy Java tym ale potrebuje nekoho kdo jim skutecne nainstaluje a nakonfiguruje JBOSS, Jenkins, Maven repository, ... a tam uz je znalost Linuxu potrebna.
Navic JBOSS i Maven generuji silene logy a spoustet to v cmd konzoli na Windows je doopravdy opruz, i kdyz podle toho co jsem videl to vetsina javistu tak delela. Moje zkusenost s Javou na Windows je takova, ze cygwin se doopgravdy hodi a nema cenu se toho bat.
Napr. chyba z JBOSS deployment descriptoru muze mit i 10KB a vsechno je to na jedne radce. Pokud se chces doopravdy podivat co ti to hlasi, tak je lepsi mit JBOSS spusteny na jine konzoili nez je cmd.exe.
-
Jeste jsem si vzpomel na jednu vyhodu Linuxu. Pokud ve firme pouzivas nejaky ynteligentni antivirus, tak se muze stat, ze ta sr*cka rozbali a analyzuje kazdy .jar soubor na ktery sahnes (behem kazde kompilace), a pokud v tom jar-u jsou dalsi archivy, tak to analyzuje rekurzivne i ty. Do dokaze spolehlive zabit perfomance kazdeho desktopu.
-
Jenom potvrdím (i vyvrátím), co už bylo několikrát napsané výše – Java ani vývoj v ní nejsou vůbec nijak vázané na Linux.
U nás ve firmě má většina vývojářů Windows, Linux má jen utlačovaná minorita. Všechny možné nutné nástroje (IDE, Maven repository, Jenkins, aplikační servery...) je možné bez problémů rozchodit i na Windows – právě proto, že jsou napsané v Javě. Navíc ty podpůrné serverové nástroje beztak obvykle spravují "ajťáci" a nikoliv sami vývojáři, a tam je ti pak v 99 % víceméně jedno, na čem to běží. Naše aplikace v produkci běží jak na Windows, tak na Linuxu, vyvíjíme i pro embedded zařízení s Windows CE. Vývojářské testování je možné na Windows, běh na Linuxu otestuje QA. Pokud se člověk vyvaruje používání čehokoliv, co může být OS specifické (timestampy souborů), respektive naučí se s tím pracovat (a je toho opravdu jen minimum), tak je vše v pohodě. Většina specifik, které je nutné řešit, se stejně týká spíš rozdílů mezi DBMS než OS.
Já osobně vyvíjím také na Windows, téměř vše dělám z IDE. Mimo IDE používám jen TortoiseGIT a TortoiseSVN. Tohle by šlo i v IDE, ale Tortoise nebo jiné podobné specializované GUI nástroje jsou ve spoustě případů lepší. Cygwin v práci nemám, jen doma, a k vývoji jej téměř vůbec nepoužiju – jen jako konzoli pro menší "domácí" aplikace. Pro enterprise aplikace, které chrlí desítky megabajtů logů za hodinu, je konzole víceméně k ničemu, naopak je třeba mít kvalitní textový editor, který je zvládne nejen otevřít, ale pak s nimi i svižně pracovat (ale to se netýká jen logů, ale i třeba nějakého většího XMLka z produkce atp.).
A také bych rád podotkl (právě tu o tom předevčírem byla diskuze), že weby jsou možná tak sotva jednotky procent veškerého kódu napsaného v Javě (byť jsi napsal, že bys je rád dělal). Jenom jsou tolik vidět, protože je to UI, vše ostatní už moc na první pohled vidět není. Až dostuduješ, a hlavně až nastoupíš do nějaké firmy, dost se ti (samy) rozšíří obzory o tom, co se všechno v Javě píše. Zmiňuji to proto, že já měl z vývoje enterprise aplikací, když jsem o nich ještě nic nevěděl, docela hrůzu, ale teď naopak vidím jako výhodu, že se nemusím dělat s UI, natož s webama. Nemusím řešit rozsypané UI, nebo jak to vypadá v deseti různých webových prohlížečích. Výstup z aplikace (logy, XMLka, JSONy atd.) si můžu zazálohovat a kdykoliv se k tomu vrátit. Běžící aplikaci pak můžu různě dráždit třeba přes JMX ;-)
PS: Na projekty v Mavenu jsou lepší NetBeans než Eclipse, protože je podporují nativně. Eclipse si dost hákuje svůj interní build na Maven lifecycle, a ten výsledek občas... jak to říct slušně... no kolegové s Eclipse v takových případech právě moc slušní nejsou.
-
Nekde se jede na Win s deployem na Linux. Ale poptavde receno - kdyz uz se ti nechce mit Linux na desktopu, tak snad radeji jit s davem a poridit si Maca. To je ted asi nejcastejsi varianta (Mac jako stanice, Linux jako server).
Jo, nejlíp MacBook 12"
-
Já osobně vyvíjím také na Windows, téměř vše dělám z IDE. Mimo IDE používám jen TortoiseGIT a TortoiseSVN. Tohle by šlo i v IDE, ale Tortoise nebo jiné podobné specializované GUI nástroje jsou ve spoustě případů lepší.
PS: Na projekty v Mavenu jsou lepší NetBeans než Eclipse, protože je podporují nativně. Eclipse si dost hákuje svůj interní build na Maven lifecycle, a ten výsledek občas... jak to říct slušně... no kolegové s Eclipse v takových případech právě moc slušní nejsou.
Evidentně jste ještě nevyzkoušel IntelliJ IDEA, tam je práce s SVN, GIT i Mavenem úplně v pohodě. Psal jste že neřešíte UI, takže by stačila i Community Edition (zadarmo).
-
Nekde se jede na Win s deployem na Linux. Ale poptavde receno - kdyz uz se ti nechce mit Linux na desktopu, tak snad radeji jit s davem a poridit si Maca. To je ted asi nejcastejsi varianta (Mac jako stanice, Linux jako server).
Jo, nejlíp MacBook 12"
MBP
-
Evidentně jste ještě nevyzkoušel IntelliJ IDEA, tam je práce s SVN, GIT i Mavenem úplně v pohodě. Psal jste že neřešíte UI, takže by stačila i Community Edition (zadarmo).
Community Edition bohužel nemá ani podporu Java EE, Spring atd., které potřebuji. Je to sice jinak špičkové IDE, ale to hlavní, co mi na ní stejně jako na Eclipse bohužel nevyhovuje, je způsob práce s Maven projekty (proto mě prosím omluvte, že házím Eclipse a IDEA z tohoto pohledu do jednoho pytle).
V Eclipse musím mít workspace a projekty do něj složitě importovat, v IDEA je to o něco jednodušší, ale je to de facto převlečené totéž. Je to pro mě problém především v případě, kdy jsou stovky sub-modulů všelijak zanořených do stromových struktur a já je nechci otevírat všechny najednou (jak kvůli přehlednosti, tak kvůli HW zdrojům). K otevřeným modulům často potřebuji otevřít jeden modul z cizího projektu, nebo více verzí téhož modulu z rozdílných branchí (které mohou navíc být vycheckoutované samostatně). V Eclipse a v IDEA je to docela problém. V NetBeans nikam nic neimportuji a nenastavuji workspace. Pouze rovnou otevřu dané Maven moduly jako projekty, a mohu si jich otevřít paralelně, kolik chci. Ihned mohu začít buildit libovolný z nich a NetBeans si samy stáhnou chybějící závislosti z Maven repository. Přímočařejší to být nemůže.
Obě IDE také vytvářejí spousty svých workspace-specifických souborů, bez kterých si neškrtnou. Pokud bych pracoval na jednom stálém projektu, nastavím SVN/GIT ignore. V cizích modulech/projektech to ale udělat jen tak nemohu a ty soubory se mi tam pak motají, v nejhorším případě je tam mohu i omylem commitnout. NetBeans berou nastavení projektu pokud možno přímo z POMu, jen v opravdu výjimečných případech pro IDE specifické nastavení modifikují POM nebo vytvoří nějaký malý soubor. Lze to ale většinou obejít globálním nastavením Mavenu. Pracovní adresář s různými indexy atd. je striktně oddělený od projektů.
Dále obě IDE mají svůj specifický build projektů (napojený na Maven lifecycle více či méně úspěšně, nebo vůbec), který nemusí dopadnou stejně jako build přímo přes Maven. NetBeans buildí Maven projekty nativně, mám tedy 99% jistotu, že na Jenkinsu pak build dopadne úplně stejně jako u mě v IDE. Ano, přiznávám jednu podstatnou nevýhodu – může to být pomalejší.
Jestli je v IDEA něco trochu jinak, než jsem napsal, tak se omlouvám, ale je to proto, že jsem to tam třeba prostě nenašel, nebo nepřišel, jak na to, protože to není tak přímočaré a intuitivní (a i to právě považuji za problém).
Pokud jde o tu práci s VCS, tak je spousta úkonů, které se nevztahují na vývoj nějakého konkrétního otevřeného modulu. Třeba high-level správa projektů, kdy chci vidět skutečný stav v souborovém systému, procházení různých repositářů atd. Občas je rychlejší i některé úpravy (třeba v POM souborech) provést v texťáku přímo ze souborového systému nebo dokonce rovnou ve VCS repository. V sebelepším IDE tohle vše může být občas těžkopádné, ale nenapsal jsem, že to zavrhuji, oba způsoby se doplňují.
-
Obě IDE také vytvářejí spousty svých workspace-specifických souborů, bez kterých si neškrtnou. Pokud bych pracoval na jednom stálém projektu, nastavím SVN/GIT ignore. V cizích modulech/projektech to ale udělat jen tak nemohu a ty soubory se mi tam pak motají, v nejhorším případě je tam mohu i omylem commitnout.
Můžeš si nastavit i globální gitignore:
git config --global core.excludesfile ~/.gitignore
A do něj pak všechny ide-specific soubory. A nejen ty, i pro vim se to hodí (.*.swp)
Trochu offtopic, ale na druhou stranu myslím že jsem zvedl užitečnost celého vlákna o desítky až stovky procent.
-
Můžeš si nastavit i globální gitignore:
git config --global core.excludesfile ~/.gitignore
A do něj pak všechny ide-specific soubory. A nejen ty, i pro vim se to hodí (.*.swp)
Pravda, na to jsem zapomněl, a v SVN od verze 1.8 je něco podobného: svn:global-ignores, to jsem zas nevěděl vůbec.
Trochu offtopic, ale na druhou stranu myslím že jsem zvedl užitečnost celého vlákna o desítky až stovky procent.
Nula od nuly pojde ;-)
-
V Eclipse musím mít workspace a projekty do něj složitě importovat, v IDEA je to o něco jednodušší, ale je to de facto převlečené totéž.
S tím velmi podstatným rozdílem že v IDEA funguje automatická synchronizace projektu podle pom.xml, zatímco v Eclipse to je takové nějaké podivné.
Je to pro mě problém především v případě, kdy jsou stovky sub-modulů všelijak zanořených do stromových struktur a já je nechci otevírat všechny najednou (jak kvůli přehlednosti, tak kvůli HW zdrojům).
V IDEA na ten top level modul použijete File - New - Project from Existing Sources a ono se to naimportuje samo, je to sice o pár kliknutí víc než v NetBeans ale nic tragického. Přehlednost je v pohodě, v pohledu Project jsou jednotlivé moduly stromově setříděné. Náročnost na HW zdroje nevnímám, prostě to funguje (SSD a dostatek RAM pokládám za samozřejmost).
K otevřeným modulům často potřebuji otevřít jeden modul z cizího projektu, nebo více verzí téhož modulu z rozdílných branchí (které mohou navíc být vycheckoutované samostatně).
Jeden modul z cizího projektu: File - New - Module from Existing Sources
Více verzí téhož modulu z rozdílných branchí: pro každou branch si dělám extra projekt, je možno mít otevřených víc projektů (každý ve svém okně).
Obě IDE také vytvářejí spousty svých workspace-specifických souborů, bez kterých si neškrtnou. Pokud bych pracoval na jednom stálém projektu, nastavím SVN/GIT ignore. V cizích modulech/projektech to ale udělat jen tak nemohu a ty soubory se mi tam pak motají, v nejhorším případě je tam mohu i omylem commitnout. NetBeans berou nastavení projektu pokud možno přímo z POMu, jen v opravdu výjimečných případech pro IDE specifické nastavení modifikují POM nebo vytvoří nějaký malý soubor. Lze to ale většinou obejít globálním nastavením Mavenu. Pracovní adresář s různými indexy atd. je striktně oddělený od projektů.
Takže modifikace pom.xml nevadí? Malý soubor nevadí? No to jsou věci. Navíc nechápu jak může vadit pokud do repository kam máte oprávnění udělat commit pošlete svn:ignore *.iml nebo .idea. Zkuste při importu pom.xml do IDEA zaškrtnout "Keep project files in" a vyplnit nějaký adresář, snad budete spokojený.
Dále obě IDE mají svůj specifický build projektů (napojený na Maven lifecycle více či méně úspěšně, nebo vůbec), který nemusí dopadnou stejně jako build přímo přes Maven.
Viděl jste vůbec naimportovaný Maven projekt v IDEA? Vždyť tam se spouští přímo Maven phase pomocí verze Mavenu kterou si určíte, s Maven profily které si vyberete!
Kdysi jsem taky používal na Maven projekty NetBeans, ale když jsem zjistil že nešlo oindexovat zdrojové kódy závislostí z Maven repository tak jsem utekl k IDEA. Byl to pro mě naprostý blocker, rozbalovat lokálně zdrojáky od všech závislostí jen aby šly oindexovat (a šlo v nich vyhledávat) bylo neskutečně otravné. Toto už sice ve verzi 8.1 dodělali, ale zpátky už jsem nepřešel.
-
...
Ale právě kvůli tomuhle všemu mi IDEA nevyhovuje. Těch pro vás "pár kliknutí navíc" je pro mě zase peklo – v každém dialogovém okně musím/můžu něco vybrat, zaškrtnout, nastavit, vyplnit... minimálně si ty možnosti musím alespoň přečíst, abych vůbec věděl, co dělám.
Nevím, v jak velkém projektu pracujete? Já si teď spočítal, že jen v trunkové branchi hlavního projektu máme téměř šest set modulů a modulů v projektu s podpůrnými knihovnami je rovněž kolem pěti set, k tomu desítky branchí pro různé verze, a tohle celé ještě vynásobeno možná dvaceti pro další projekty odvozené z hlavního projektu. Náplní dobré poloviny mé práce je neustále někde něco analyzovat, odpovídat každou chvíli na dotěrné otázky kolegů ohledně kódu, nad kterým jako naschvál zrovna vůbec nepracuji (a druhá polovina práce jsou administrativní zbytečnosti, jo kdybych tak měl možnost přijít do práce, sednout k jednomu úkolu, pracovat na něm do večera a pak jít domů). A k tomu potřebuji stále otevírat a zavírat moduly tak, jak jsem popsal. Naše stromová struktura zase není tolik hluboká, abych si vše mohl dovolit otevřít ve stromečku a zároveň nic nepřekáželo (jedna rozbalená větev vezme téměř celou obrazovku). A při individuálním otevírání by mě zase v takovém počtu modulů těch "pár kliknutí navíc" zničilo.
Abyste ale neřekl... vše, co jste napsal, si tu poctivě zkouším, ale bohužel ne... ta jednoduchost a přímočarost NetBeans tam prostě není ;-) Každý má jiné priority a pro mě je tohle tak klíčové, že NetBeans odpustím, že mají ze všech tří "velkých" IDE možná nejméně funkcí a spoustu jiných nedokonalostí.
PS: RAM není nikdy dost.
Kdysi jsem taky používal na Maven projekty NetBeans, ale když jsem zjistil že nešlo oindexovat zdrojové kódy závislostí z Maven repository tak jsem utekl k IDEA. Byl to pro mě naprostý blocker, rozbalovat lokálně zdrojáky od všech závislostí jen aby šly oindexovat (a šlo v nich vyhledávat) bylo neskutečně otravné. Toto už sice ve verzi 8.1 dodělali, ale zpátky už jsem nepřešel.
Ano, tohle byl velký zásek, někteří kolegové eclipsáři se mi dříve zrovna kvůli tomuto sem tam vysmívali. Ale mě to zase tolik neomezovalo, 3rd party závislostí nepoužíváme tolik (hlavně nemusíme moc zkoumat jejich kód), a naše vlastní knihovny si mohu jednoduše otevřít.
-
Ale právě kvůli tomuhle všemu mi IDEA nevyhovuje. Těch pro vás "pár kliknutí navíc" je pro mě zase peklo – v každém dialogovém okně musím/můžu něco vybrat, zaškrtnout, nastavit, vyplnit... minimálně si ty možnosti musím alespoň přečíst, abych vůbec věděl, co dělám.
Naučit se používat nástroje možná není jednoduché, ale je to velmi dobrá investice pro budoucí efektivitu práce. Pro začátek má IDEA v dialogových oknech předvyplněné rozumné defaulty.
potřebuji stále otevírat a zavírat moduly tak, jak jsem popsal. Naše stromová struktura zase není tolik hluboká, abych si vše mohl dovolit otevřít ve stromečku a zároveň nic nepřekáželo (jedna rozbalená větev vezme téměř celou obrazovku). A při individuálním otevírání by mě zase v takovém počtu modulů těch "pár kliknutí navíc" zničilo.
Vytvořit IDEA projekt z top-level pom.xml je trochu práce, ale jen málo a hlavně pro jednu branch se to dělá jen jednou! Pak už se ten projekt automaticky synchronizuje se změnami v pom.xml (top-level i podřízenými). Potom už jen otevíráte a zavíráte IDEA projekty podle toho kterou branch potřebujete - zkuste to a uvidíte že to není složitější než v NetBeans, jde jen o to jednorázové nastavení.
-
Naučit se používat nástroje možná není jednoduché, ale je to velmi dobrá investice pro budoucí efektivitu práce. Pro začátek má IDEA v dialogových oknech předvyplněné rozumné defaulty.
Souhlasím, ale na druhou stranu spoustu úkonů zase dělá člověk jen jednou za čas a mezitím zapomene, jak přesně na to. Zde se určitá intuitivnost hodí, aby člověk snáze našel to, co hledá. Nemluvím teď zrovna o tom způsobu práce s projekty, ale o celkovém konceptu a filosofie práce v jakékoliv aplikaci (práce s projekty jde jen ruku v ruce s tím).
Vytvořit IDEA projekt z top-level pom.xml je trochu práce, ale jen málo a hlavně pro jednu branch se to dělá jen jednou! Pak už se ten projekt automaticky synchronizuje se změnami v pom.xml (top-level i podřízenými). Potom už jen otevíráte a zavíráte IDEA projekty podle toho kterou branch potřebujete - zkuste to a uvidíte že to není složitější než v NetBeans, jde jen o to jednorázové nastavení.
Beztak myslím, že to není úplně to pravé ořechové v případě jednotlivých malých projektů, které si jen dočasně vycheckoutuji, abych si je mohl na chvíli otevřít v IDE, a pak je zase hned smažu. Nicméně není to zas tak častý případ, tak až se k ní zase vrátím, snad si vzpomenu na tohle vlákno a zkusím to. Dnes jsem tím zabil půl dne a to mi stačí ;-) Pro seriozní práci bych si stejně musel koupit placenou verzi (kvůli Java EE) a to se mi nechce.
-
Popravde trocha zvazujem aj ze sa dam na .NET, prave kvoli windowsu
Jak už psali ostatní, není problém vyvíjet ve Windows. Osobně bych si radši vybral .NET, protože se toho v něm dá napsat víc, včetně "plné" desktopové aplikace nebo servisu, ale každému co jeho jest.
-
Nevím, v jak velkém projektu pracujete? Já si teď spočítal, že jen v trunkové branchi hlavního projektu máme téměř šest set modulů a modulů v projektu s podpůrnými knihovnami je rovněž kolem pěti set, k tomu desítky branchí pro různé verze, a tohle celé ještě vynásobeno možná dvaceti pro další projekty odvozené z hlavního projektu...
Kde že prosím tě pracuješ? Ať vím, jaké firmě se rovnou vyhnout. :)
-
Kde že prosím tě pracuješ? Ať vím, jaké firmě se rovnou vyhnout. :)
Jo, já to prozradím, a pak už tam také další den nebudu muset chodit ;-)