abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 10:44 | Komunita

Společně s openSUSE Conference 2018 probíhá dnes v Praze na Fakultě informačních technologií ČVUT jednodenní seminář CryptoFest 2018 (Twitter). Přednášky lze sledovat online na YouTube nebo na CCC.

Ladislav Hagara | Komentářů: 0
dnes 02:22 | Komunita

Barton George, zakladatel a vedoucí projektu Sputnik, představil na svém blogu čtyři nové mobilní pracovní stanice Dell Precision s předinstalovaným Ubuntu. Jedná se o modely 3530, 5530, 7530 a 7730. Mobilní pracovní stanice budou certifikovány pro RHEL 7.5.

Ladislav Hagara | Komentářů: 4
dnes 01:11 | Nová verze

Vyšla verze 5.12 prohlížeče map a GPS logů GPXSee. Nová verze přidává podporu Garmin JNX map a přináší mírné zlepšení výkonu/UX.

Martin Tůma | Komentářů: 0
včera 12:11 | Komunita

V Praze na Fakultě informačních technologií ČVUT probíhá openSUSE Conference 2018. Přednášky lze sledovat také online. Aktuální dění lze sledovat na Twitteru. Stisknutím zeleného tlačítka bylo dnes dopoledne vydáno openSUSE Leap 15.0.

Ladislav Hagara | Komentářů: 6
včera 11:44 | Komunita

Na Steamu probíhá do 28. května akce s názvem Spring Cleaning (Jarní úklid). V rámci akce lze hrát hry Don't Starve Together, Cities: Skylines, Tyranny, Borderlands 2, Middle-earth: Shadow of Mordor a Left 4 Dead 2 běžící na Linuxu zdarma [GamingOnLinux].

Ladislav Hagara | Komentářů: 2
24.5. 23:23 | Humor

Nová služba České pošty nazvaná Bezpečné úložiště nabízí až 100GB kapacitu pro "bezpečnou správu Vašich dat pod patronací důvěryhodného partnera Česká pošta".

… více »
Lol Phirae | Komentářů: 56
24.5. 22:14 | Bezpečnostní upozornění

Nova kritická hrozba VPNfilter bola zistená po dlhšiej spolupráce Talos s verejnými i súkromnými bezpečnostnými agentúrami. VPNfilter ohrozuje približne 500 000 zariadení v približne 54 krajinach. Zasiahnutí výrobcovia sú Linksys, MikroTik, NETGEAR, TP-Link (SOHO), QNAP (NAS). Správanie malwaru je nebezpečnej povahy, čo môže v určitých prípadoch spôsobiť škody veľkého rozsahu. Často tieto zariadenia sú na perimetri sieťe bez ochrany.

ewew | Komentářů: 5
24.5. 21:55 | Pozvánky

CSNOG (Czech and Slovak Network Operators Group), první československé setkání síťových operátorů, se uskuteční 11. a 12. června v Brně. Akce je určena poskytovatelům internetového připojení, síťovým operátorům, provozovatelům registrů, internetovým odborníkům a všem zájemcům o internetové a síťové technologie. Program je zaměřený na odborná, technická témata jako například síťová architektura, bezpečnost sítí, zpracování dat, DNS a další. Nutná je registrace.

Ladislav Hagara | Komentářů: 0
24.5. 21:33 | Komunita

Na Humble Bundle lze získat počítačovou hru, simulátor hackování, Hacknet (Wikipedie, YouTube) běžící také v Linuxu zdarma. Tentokrát je ke stažení také verze bez DRM a navíc soundtrack. Speciální akce končí v sobotu v 19:00.

Ladislav Hagara | Komentářů: 0
23.5. 20:11 | Zajímavý software

Alexandre Julliard oznámil jménem vývojového týmu Wine vydání první verze 1.0 knihovny vkd3d určené pro překlad volání Direct3D 12 na Vulkan. Zdrojové kódy vkd3d jsou k dispozici pod licencí LGPLv2.1+.

Ladislav Hagara | Komentářů: 1
Používáte pro některé služby inetd?
 (35%)
 (23%)
 (42%)
Celkem 155 hlasů
 Komentářů: 5, poslední 22.5. 16:46
    Rozcestník

    Dotaz: zaciatok projektu: na zelenej luke

    25.7.2016 18:31 exoskeleton
    zaciatok projektu: na zelenej luke
    Přečteno: 708×

    dobry den,

    sme mala developerska firmicka (3 ludia) a robime mobilne aplikacie. ako verzovaci nastroj pouzivame SVN. IDE Eclipse. Pre kazdu zakazku/projekt mame zvlast repozitar.

    Dostali sme sa ku vacsiemu projektu ktory bude mat backend (asi tomcat), frontend (web), GUI (client). Client bude mat moznost pouzivat pluginy. Rad by som sa opytal aky zvolit model vyvoja a verzovania?

    1) je nacase sa zamysliet nad Gitom?

    2) drzat vsetko ako jeden projekt v Eclipse?

    3) drzat vsetko v jednom repozitari a zvlast branche pre client/pluginy/web/backend?

    4) rozdelit to na jednotlive projekty a mat zvlast repozitare?

    dakujem

    Odpovědi

    26.7.2016 03:03 Sten
    Rozbalit Rozbalit vše Re: zaciatok projektu: na zelenej luke
    1. Git bych doporučil pro cokoliv. V „nejhorším“ lze použít git-svn a server mít stále na SVN, ale pokud se naučíte s Gitem pracovat (a poznáte i webové nástroje jako GitLab), už se k SVN nebudete chtít vracet.
    2. Určitě ne. Jsou to tři oddělené části, měly by mít (nejméně) tři Eclipse projekty. (Ale mohou být v jednou workspace; doporučuji workspace per repozitář, takže záleží na rozdělení dále.)
    3. Větve podle projektů nedělejte, Git to nepotřebuje a dost to zhoršuje synchronizaci mezi projekty. Doporučil bych nastudovat Git-flow, které docela dobře vysvětluje, k čemu větve slouží, a doporučuje jeden způsob, jak je používat.
    4. Jestli mít každý projekt jako samostatný repozitář nebo to mít v jednom, záleží hodně na tom, jak moc budou na sobě jednotlivé části záviset. Obecně bych dal dohromady backend+frontend (API mezi nimi asi nebude úplně stabilní, takže je vhodné držet dohromady odpovídající verze) a oddělil klienta (API by mělo být stabilní, jinak to zákazníkům rozbijete, takže to není vázané na konkrétní verzi serveru), ale i všechno dohromady by pro Git nebyl žádný problém.
    AraxoN avatar 26.7.2016 19:53 AraxoN | skóre: 45 | blog: slon_v_porcelane | Košice
    Rozbalit Rozbalit vše Re: zaciatok projektu: na zelenej luke

    1) je nacase sa zamysliet nad Gitom?

    Čím skôr, tým lepšie. Marš na CZ.NIC a stiahni knihu Pro Git - veľmi Ti pomôže.

    2) drzat vsetko ako jeden projekt v Eclipse?

    Nie.

    3) drzat vsetko v jednom repozitari a zvlast branche pre client/pluginy/web/backend?

    Nie, branče slúžia na niečo úplne iné. Až prejdeš na Git tak to pochopíš. SVN Ti túto vedomosť nemal ako sprostredkovať.

    4) rozdelit to na jednotlive projekty a mat zvlast repozitare?

    Jeden repozitár nie je pre Git problém, ale SVN z toho dostane záhul (moja skúsenosť). Ak ale máš podprojekty, ktoré spolu súvisia len cez API, asi by som ich aj tak oddelil do samostatných repozitárov.
    A fine is a tax for doing wrong. A tax is a fine for doing well.
    28.7.2016 12:52 exoskeleton
    Rozbalit Rozbalit vše Re: zaciatok projektu: na zelenej luke
    rozhodli sme sa pre model projekt per repozitar. pricom budeme mat samostane projekty pre backend, frontend, klient, pluginy. a vsetko to bude v jednom Eclipse workspace pre lepsiu orientaciu.

    budeme sa chvilu hrat s gitom a uvidime ci premigrovat vsetky doterajsie projekty alebo nie, predsa len drzat 2 verzovacie systemy pre malu firmicku je overkill.

    dakujem za rady aj za tip na knihu o Gite v zrozumitelnom jazyku :).

    28.7.2016 15:22 Sten
    Rozbalit Rozbalit vše Re: zaciatok projektu: na zelenej luke
    Doporučuji mít workspace per repozitář, hodně to zjednodušuje správu nastavení pro ten workspace. Pokud vám víc vyhovuje mít všechno v jednom workspace, bude lepší to mít i v jednom repozitáři, problémy s konflikty při práci různých lidí na různých částech v Gitu na rozdíl od SVN nejsou (z podstaty distribuovaného VCS). Rozdělit existující repozitář je v případě potřeby docela snadné, sloučit rozdělené repozitáře je hodně těžké. (Stejně jsme postupovali i u nás, když se přecházelo ze SVN na Git, každá část měla svůj repozitář. O dva roky později jsme to pracně slučovali, protože se s tím pracovalo hrozně blbě, závislosti to při přepínání větví neustále rozbíjely a webové nástroje si s tím nedokázaly poradit.)
    28.7.2016 17:06 Kit | skóre: 41 | Brno
    Rozbalit Rozbalit vše Re: zaciatok projektu: na zelenej luke
    "workspace per repozitář" - OK, nemám námitek.

    Co se myslí tím rozbíjením závislostí při přepínání větví? Rozhrani mezi moduly by mělo být neměnné, resp. může se pouze rozšiřovat.
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    28.7.2016 20:23 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: zaciatok projektu: na zelenej luke
    Co se myslí tím rozbíjením závislostí při přepínání větví?

    Pokud budete mít podprojekty v samostatných repozitářích, bude těžké udržet přehled o tom, který snapshot podprojektu A je kompatibilní s kterým snapshotem podprojektu B. Pro posloupnost klasických release verzí se to ještě asi uhlídat dá, ale třeba při bisectu, kdy potřebujete přeložit a otestovat zcela obecné snapshoty, si to moc představit neumím.

    Rozhrani mezi moduly by mělo být neměnné

    To je chvályhodné předsevzetí, ale… Pane Smrtko, proč vy se pořád tak usmíváte?

    28.7.2016 20:59 Kit | skóre: 41 | Brno
    Rozbalit Rozbalit vše Re: zaciatok projektu: na zelenej luke
    Tak snad se v každém projektu uvádí, kterou minimální verzi jiného podprojektu vyžaduje. Také existují anotace "deprecated" a podobné mechanismy.
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    28.7.2016 21:10 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: zaciatok projektu: na zelenej luke
    Jak jsem už napsal, dokud se můžeme bavit o nějakém omezeném počtu verzí, tak to ještě jde. Tady se ale bavíme o gitu a jednotlivých commitech, kterých může být spousta a které ani nejsou lineárně uspořádané.
    28.7.2016 21:19 Kit | skóre: 41 | Brno
    Rozbalit Rozbalit vše Re: zaciatok projektu: na zelenej luke
    V Gitu existují také nějaké větve, z nichž většina do produkce prostě nejde. Kombinovat nějaké větve typu develop nebo dokonce feature prostě nemá význam.

    Gitflow
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    28.7.2016 21:27 Sten
    Rozbalit Rozbalit vše Re: zaciatok projektu: na zelenej luke
    V SVN je to jednoduché, revize rostou lineárně, takže pokud máte revizi 172 a podprojekt má napsáno, že vyžaduje 154+, tak by to mělo fungovat. Git ale nemá lineární historii, takže se nemůže číslovat lineárně, a pokud řeknete, že podprojekt vyžaduje commit aa725d4, tak není na první pohled jasné, jestli commit 57adf45 je jeho potomek (vyhovuje) nebo je to předek nebo třeba bratranec (nevyhovuje). Dá se to udržovat, ale je s tím spousta práce, a pokud nemáte silný důvod to rozdělovat hned na začátku (budete vyvíjet víc klientů, klient bude open source ap.), nerozděloval bych to. Rozdělit se to dá později.
    28.7.2016 21:41 Kit | skóre: 41 | Brno
    Rozbalit Rozbalit vše Re: zaciatok projektu: na zelenej luke
    K tomuto účelu se používají tagy.

    Aby nedošlo k mýlce: Nevidím důvod, proč by se měl projekt uměle rozdělovat v místech, kde by mohla vzniknout silná závislost mezi moduly, ale spíš tam, kde by si různé týmy vývojářů mohly vzájemně lézt do zelí.
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    28.7.2016 21:15 Sten
    Rozbalit Rozbalit vše Re: zaciatok projektu: na zelenej luke
    Poměrně často se nám stávalo, že při přepínání z master na různé release větve vývojář zapomněl přepnout všechny repozitáře, což pak mohlo mít za následek nefungující prostředí. Odhalí se to rychle, ale až po zkompilování a spuštění všeho, a to nějaký čas zabere, a je otravné na to muset pořád myslet (takže jsme pro to měli skript, který ale třeba při nekomitnutých změnách na některých repozitářích selhal a nastal stejný problém). Pak to dost ovlivňovalo CI server, někdo založil novou release větev, ale zapomněl nastavit všechny repozitáře, aby ji používaly, což nakonec může dostat do produkce i vadný produkt (Ci server otestuje místo nefunkčního releasu master, který projde). A takové věci jako merge/pull requesty jsou opravdu lahůdka, protože schvalující musí zkontrolovat změny ve všech repozitářích, než může změnu schválit. Pokud schválí změnu v jednom repozitáři, ale má potom výhradu ve druhém, klidně to může skončit ve stavu, kdy větev nefunguje. Nebo se může stát, že schválí změnu v jednom repozitáři, ale v dalším repozitáři mezitím někdo jiný schválí jinou změnu, dojde k merge conflictu, změna schválit nejde a zase je rozbitá větev.
    28.7.2016 21:26 Kit | skóre: 41 | Brno
    Rozbalit Rozbalit vše Re: zaciatok projektu: na zelenej luke
    Tak snad se vždy pracuje jen na kódu jednoho repozitáře, ne? Každý se kompiluje a testuje extra a každá změna se schvaluje také extra - nezávisle na ostatních repozitářích. Jinak to dělení do více repozitářů postrádá na významu.

    Repozitáře prostě musí být na sobě zcela nezávislé.
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    28.7.2016 21:43 Sten
    Rozbalit Rozbalit vše Re: zaciatok projektu: na zelenej luke
    To není tak jednoduché, pokud zavádíte nové vlastnosti. Znamená to zahodit agilní vývoj a vytvářet přesné specifikace, aby se vám nestalo, že v půlce vývoje, kdy už máte hotovou změnu na backendu, zjistíte, že na frontendu to vlastně takhle nemůže fungovat a rozhraní s backendem by mělo být jiné (v agilním vývoji to není problém, API se mění celou dobu, dokud není hotovo). A ano, v Gitu postrádá takové dělení smysl, v SVN je ale nezbytné, jinak si budou různí vývojáři blokovat práci, a tak spousta lidí přecházejících ze SVN do Gitu má tendence mít těch repozitářů co nejvíc.
    28.7.2016 21:56 Kit | skóre: 41 | Brno
    Rozbalit Rozbalit vše Re: zaciatok projektu: na zelenej luke
    Proto by rozhraní mělo být tenké, aby změna specifikace v jednom modulu neměla vliv na specifikaci v druhém modulu. Jinak to rozdělování nedává smysl a je lepší to nechat pohromadě.

    Mezi dvěma commity by se také neměl modifikovat víc než jeden soubor a před commitem by měl projít testy.
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    29.7.2016 00:21 Sten
    Rozbalit Rozbalit vše Re: zaciatok projektu: na zelenej luke
    Proč by se neměl modifikovat víc než jeden soubor? Je normální, že se v jednom commitu modifikuje několik souborů, třeba v Javě interface a implementace, v C++ hlavičkový a zdrojový souboru, mnohdy i dokumentace, testy nebo Makefile. Větší commity v kernelu modifikují klidně i desítky souborů. Případné merge conflicty budou stejně naprosto totožné, protože Git každý soubor merguje samostatně.
    29.7.2016 01:07 Kit | skóre: 41 | Brno
    Rozbalit Rozbalit vše Re: zaciatok projektu: na zelenej luke
    Když změníš více souborů, tak se blbě píše komentář, co jsi vlastně modifikoval. Pokud commituješ jen jeden soubor, tak se mnohem snáze "cestuje časem".

    Nejdříve změním interface a postupně všechny jeho implementace. Hezky po jednom.

    Dokumentace se nachází ve stejném souboru jako zdroják, takže i když ho změníš současně se zrojákem, je to stále změna v jednom souboru.

    Modifikace Makefile stojí za zcela samostatný commit. Moc často se nedělá a je dobré, když je v historii dobře vidět.

    Napsal jsem "neměl by", nikoli "nesmí". V SVN mnozí commitují jen 1× denně, což je špatně. V Gitu když uděláš commit 3× za minutu, tak je to stále v pohodě.

    Většinou totiž dělám na jednom souboru (např. třídě), dokud ho nemám hotový. Do ostatních souborů přitom (zpravidla) nezasahuji. To snižuje i počty merge konfliktů.
    Komentáře označují místa, kde programátor udělal chybu nebo něco nedodělal.
    29.7.2016 04:14 Sten
    Rozbalit Rozbalit vše Re: zaciatok projektu: na zelenej luke
    Proč by se psal blbě komentář, co jsem modifikoval? Přijde ti třeba, že se tenhle komentář musel blbě psát? Je to jedna změna ve čtyřech souborech.

    Mě se mnohem lépe cestuje časem, když při tom nemusím procházet každý jeden krok, jak se ty párky vyráběly. Ono stejně není nijak zajímavé, jestli se po změně interface napřed měnila tahle konkrétní implementace nebo nějaká jiná.

    git log --stat u každého commitu vypíše, jaké soubory se měnily. Psát to do komentáře je zbytečné.

    Pokud chci vidět modifikace Makefile, tak stačí zavolat git log Makefile (případně git blame Makefile, pokud mě zajímá, kdo tam změnil konkrétní řádek).

    Dokumentace není jen ve zdrojáku. Zdroják popisuje API, ale těžko bude popisovat třeba to, jak se daná aplikace instaluje a debuguje, s jakými formáty souborů pracuje či jak jsou zdrojáky organizované.
    29.7.2016 07:09 Michal Kubeček | skóre: 71 | Luštěnice
    Rozbalit Rozbalit vše Re: zaciatok projektu: na zelenej luke

    Takže radši budete mít v gitu polovinu commitů, které nejspíš nepůjdou ani přeložit, natož aby fungovaly? Happy bisecting… Nemluvě o tom, že ani samotné tvrzení, že se bude hůř psát commit message, mi nedává moc smyslu.

    Promiňte mi mou upřímnost (a přímost), ale celá druhá část této diskuse na mne působí, jako kdybyste nikdy s žádným netriviálním projektem do kontaktu nepřišel, ale nejsa nezatížen praktickými zkušenostmi, vytyčil jste jakési teoretické zásady a teď na nich lpíte, přestože lidé, kteří praktické zkušenosti mají, se vám snaží vysvětlit, že nejsou moc v souladu s tím, jak takový vývoj v praxi funguje.

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.