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 16:22 | Nová verze

Po pěti měsících od vydání Waylandu a Westonu 1.12.0 oznámil Bryce Harrington (Samsung) vydání Waylandu 1.13.0 a Westonu 2.0.0.

Ladislav Hagara | Komentářů: 0
24.2. 13:37 | Bezpečnostní upozornění

Společnost Cloudflare (Wikipedie) na svém blogu potvrdila bezpečnostní problém s její službou. V požadovaných odpovědích od reverzní proxy byla odesílána také data z neinicializované paměti. Útočník tak mohl získat cookies, autentizační tokeny, data posílaná přes HTTP POST a další citlivé informace. Jednalo se o chybu v parsování HTML. Zneužitelná byla od 22. září 2016 do 18. února 2017. Seznam webů, kterých se bezpečnostní problém potenciálně týká na GitHubu.

Ladislav Hagara | Komentářů: 1
24.2. 08:22 | Nová verze

Byla vydána první beta verze Ubuntu 17.04 s kódovým názvem Zesty Zapus. Ke stažení jsou obrazy Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu GNOME, Ubuntu Kylin, Ubuntu Studio a Xubuntu. Dle plánu by Ubuntu 17.04 mělo vyjít 13. dubna 2017.

Ladislav Hagara | Komentářů: 28
23.2. 17:53 | Bezpečnostní upozornění

Google na svém blogu věnovaném počítačové bezpečnost informuje o nalezení "reálného" způsobu generování kolizí hašovací funkce SHA-1. Podrobnosti a zdrojové kódy budou zveřejněny do 90 dnů. Již dnes lze ale na stránce SHAttered nalézt 2 pdf soubory, jejichž obsah se liší a SHA-1 otisk je stejný (infografika).

Ladislav Hagara | Komentářů: 33
23.2. 17:51 | Nová verze

Vyšla nová verzia open source software na správu a automatizáciu cloudových datacentier Danube Cloud 2.4. Danube Cloud je riešenie postavené na SmartOS, ZFS, KVM a zónach. Obsahuje vlastnosti ako integrovaný monitoring, DNS manažment, zálohy, a samozrejme rozsiahlu dokumentáciu.

dano | Komentářů: 8
23.2. 17:46 | Pozvánky

V Plzni se 3. až 5. března 2017 uskuteční AIMTEChackathon. Je to akce pro vývojáře, grafiky, webdesignéry i veřejnost. Akci provází zajímavé přednášky IT odborníků. Více o programu a možnosti přihlášení na stránkách akce.

cuba | Komentářů: 0
23.2. 01:00 | Nová verze

Známý šifrovaný komunikátor Signal od verze 3.30.0 již nevyžaduje Google Play Services. Autoři tak po letech vyslyšeli volání komunity, která dala vzniknout Google-free forku LibreSignal (dnes již neudržovaný). Oficiální binárky jsou stále distribuované pouze přes Google Play, ale lze použít neoficiální F-Droid repozitář fdroid.eutopia.cz s nezávislými buildy Signalu nebo oficiální binárku stáhnout z Google Play i bez Google účtu

… více »
xm | Komentářů: 8
22.2. 23:14 | Nová verze

Po třech týdnech od vydání první RC verze byla vydána první stabilní verze 17.01.0 linuxové distribuce pro routery a vestavěné systémy LEDE (Linux Embedded Development Environment), forku linuxové distribuce OpenWrt. Přehled novinek v poznámkách k vydání. Dotazy v diskusním fóru.

Ladislav Hagara | Komentářů: 8
22.2. 17:28 | Bezpečnostní upozornění

Byly zveřejněny informace o bezpečnostní chybě CVE-2017-6074 v Linuxu zneužitelné k lokální eskalaci práv. Jde o chybu v podpoře DCCP (Datagram Congestion Control Protocol). Do linuxového jádra se dostala v říjnu 2005. V upstreamu byla opravena 17. února (commit). Bezpečnostní chyba byla nalezena pomocí nástroje syzkaller [Hacker News].

Ladislav Hagara | Komentářů: 16
22.2. 15:00 | Zajímavý software

Společnost Valve vydala novou beta verzi SteamVR. Z novinek lze zdůraznit oficiální podporu Linuxu. Další informace o podpoře této platformy pro vývoj virtuální reality v Linuxu v diskusním fóru. Hlášení chyb na GitHubu.

Ladislav Hagara | Komentářů: 0
Jak se stavíte k trendu ztenčování přenosných zařízení (smartphony, notebooky)?
 (13%)
 (2%)
 (72%)
 (3%)
 (10%)
Celkem 709 hlasů
 Komentářů: 66, poslední 22.2. 18:57
    Rozcestník

    Dotaz: zaciatok projektu: na zelenej luke

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

    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.