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í
×
včera 21:55 | Komunita

Nadace pro svobodný software (FSF) oznámila aktualizaci seznamu prioritních oblastí (changelog), na které by se měli vývojáři a příznivci svobodného softwaru zaměřit. Jsou to například svobodný operační systém pro chytré telefony, hlasová a video komunikace nebo softwarový inteligentní osobní asistent.

Ladislav Hagara | Komentářů: 1
včera 16:44 | Nová verze

Byla vydána verze 2.0.0 knihovny pro vykreslování grafů v programovacím jazyce Python Matplotlib (Wikipedie, GitHub). Přehled novinek a galerie grafů na stránkách projektu.

Ladislav Hagara | Komentářů: 0
včera 15:33 | Komunita

V australském Hobartu probíhá tento týden konference linux.conf.au 2017. Na programu je celá řada zajímavých přednášek. Sledovat je lze online.

Ladislav Hagara | Komentářů: 0
včera 10:20 | Zajímavý článek

Pavel Tišnovský se v dvoudílném článku na MojeFedora.cz věnuje bitmapovým (rastrovým) grafickým editorům ve Fedoře. V prvním dílu se věnuje editorům MyPaint, MtPaint, Pinta, XPaint, Krita a GIMP. V pokračování pak editorům GNU Paint (gpaint), GrafX2, KolourPaint, KIconEdit a Tux Paint.

Ladislav Hagara | Komentářů: 1
16.1. 17:11 | Komunita

Byl proveden bezpečnostní audit svobodného IMAP a POP3 serveru Dovecot (Wikipedie). Audit byl zaplacen z programu Mozilla Secure Open Source a provedla jej společnost Cure53. Společnost Cure53 byla velice spokojena s kvalitou zdrojových kódu. V závěrečné zprávě (pdf) jsou zmíněny pouze 3 drobné a v upstreamu již opravené bezpečnostní chyby.

Ladislav Hagara | Komentářů: 0
16.1. 15:30 | IT novinky

Nadace Raspberry Pi představila na svém blogu Raspberry Pi Compute Module 3 (CM3 a CM3L), tj. zmenšené Raspberry Pi vhodné nejenom pro průmyslové využití. Jedná se o nástupce Raspberry Pi Compute Module (CM1) představeného v dubnu 2014. Nový CM3 vychází z Raspberry Pi 3 a má tedy dvakrát více paměti a desetkrát větší výkon než CM1. Verze CM3L (Lite) je dodávána bez 4 GB eMMC flash paměti. Uživatel si může připojit svou vlastní. Představena byla

… více »
Ladislav Hagara | Komentářů: 1
16.1. 01:23 | Nová verze

Oficiálně bylo oznámeno vydání verze 3.0 multiplatformního balíku svobodných kancelářských a grafických aplikací Calligra (Wikipedie). Větev 3 je postavena na KDE Frameworks 5 a Qt 5. Krita se osamostatnila. Z balíku byly dále odstraněny aplikace Author, Brainstorm, Flow a Stage. U Flow a Stage se předpokládá jejich návrat v některé z budoucích verzí Calligry.

Ladislav Hagara | Komentářů: 7
15.1. 15:25 | Nová verze

Bylo oznámeno vydání první RC (release candidate) verze instalátoru pro Debian 9 s kódovým názvem Stretch. Odloženo bylo sloučení /usr jako výchozí nastavení v debootstrap. Vydán byl také Debian 8.7, tj. sedmá opravná verze Debianu 8 s kódovým názvem Jessie.

Ladislav Hagara | Komentářů: 6
15.1. 13:37 | Zajímavý projekt

1. ledna byl představen projekt Liri (GitHub). Jedná se o spojení projektů Hawaii, Papyros a původního projektu Liri s cílem vyvíjet operační systém (linuxovou distribuci) a aplikace s moderním designem a funkcemi. Včera byl představen Fluid 0.9.0 a také Vibe 0.9.0. Jedná se o toolkit a knihovnu pro vývoj multiplatformních a responzivních aplikací podporující Material Design (Wikipedie) a volitelně také Microsoft Design Language (designový jazyk Microsoft) [reddit].

Ladislav Hagara | Komentářů: 8
14.1. 00:33 | Zajímavý software

Google na svém blogu věnovaném open source představil knihovnu pro komprimaci a dekomprimaci 3D grafiky s názvem Draco. Knihovna bude využívána například v aplikacích pro virtuální a rozšířenou realitu. Porovnání Draco s gzip na YouTube. Zdrojové kódy Draco jsou k dispozici na GitHubu pod licencí Apache 2.0.

Ladislav Hagara | Komentářů: 5
Jak se stavíte k trendu ztenčování přenosných zařízení (smartphony, notebooky)?
 (10%)
 (2%)
 (75%)
 (3%)
 (10%)
Celkem 304 hlasů
 Komentářů: 24, poslední včera 10:14
    Rozcestník
    Reklama

    Dotaz: zaciatok projektu: na zelenej luke

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

    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: 37 | 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: 37 | 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: 37 | 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: 37 | 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: 37 | 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: 37 | 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: 37 | 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.