Příspěvky

5161

Vývoj / Re:Proč bych měl přejít ze SVN na GIT? (vážně)

« kdy: 31. 07. 2014, 11:44:31 »

A o tom, že mohu mít v SVN naráz víc WC asi nevíte co? Takhle se to přece dělá ne?

Jenže to pak musíte mít na disku jeden projekt vícekrát, u všech skriptů nebo nástrojů musíte rozlišovat, se kterou variantou projektu mají zrovna pracovat…

5162

Server / Re:apache forwardovani ftp

« kdy: 31. 07. 2014, 11:40:53 »

Chcete ty soubory tedy uživatelům zpřístupnit přes HTTP nebo přes FTP?

5163

Sítě / Re:GSM wi-fi router Huawei nebo jiný

« kdy: 31. 07. 2014, 08:10:28 »

Něco podobného od TP-Linku: http://www.czc.cz/tp-link-tl-mr3020/101250/produkt Spíš bych použil tento typ zařízení (zvlášť WiFi router, který umí komunikovat s USB modeme, a zvlášť modem) – pokud budete potřebovat vyměnit jednu nebo druhou část, nemusíte měnit celé zařízení (např. když budete chtít přejít na CDMA nebo LTE).

5164

Vývoj / Re:Proč bych měl přejít ze SVN na GIT? (vážně)

« kdy: 31. 07. 2014, 07:05:37 »

Přesně tak, hlavně zásadní "výhodu" spatřuju v tom, že v centrálně řízené organizaci není DVCS nutný, naopak jednotlivý programátoři musí být zastupitelní

Žádné přesně tak, způsob řízení ani zastupitelnost programátorů vůbec nesouvisí s tím, zda vyvíjíte na jedné společné hromadě zdrojáků, nebo zda vyvíjíte tak, že vytváříte a aplikujete jednotlivé změny.

Zatím jsem jen slyšel, že je to moderní standard.

Záleží na tom, čemu říkáte "slyšel". Pokud tomu, že to "zaznělo" ve vaší přítomnosti, pak jste toho slyšel mnohem víc. Pokud tomu, že jste to vzal na vědomí, protože je to v souladu s tím, co slyšet chcete, pak jste toho asi opravdu o moc víc neslyšel - ale není to chyba ostatních diskutujících.

Obdivuju váš čas si s tím hrát. Já zpravidla programuju lineárně. Bych si klidně udělal tisíce větví, beztak by tam jen hnily.

Pracuju na nějaké větší změně, mezi tím přijde někdo, že pro jeho změnu potřebuje nějakou úpravu ode mne. Pak zase já pro tu větší změnu potřebuju úpravu od někoho jiného a musím počkat, než ji dodělá, tak mezi tím dělám na něčem jiném. A do toho je potřeba průběžně opravovat chyby, které se objeví. Pokud můžete dělat vždy jen na jedné věci a nemusíte opravovat žádné chyby,  asi můžete programovat lineárně. Ale moc vás takových nebude.

Celé je to o tom PROČ by se měl měnit zaběhnutý systém? Proč by měla společnost s centrálními repozitáři přecházet na git?

Protože pak vývojáři pracují efektivněji. Netráví čas zbytečně opakovaným prováděním těch samých změn na zdrojových kódech (různé větvení a spojování), místo toho se mohou věnovat vývoji. Ale jak už jsem psal, vývojáři jsou často velmi konzervativní a neměnit zaběhnutý systém je často velice silný argument pro starý systém. Ostatně vidíme to na vás.
Jinak pokud vám připadá Git složitý na používání, zkuste Mercurial - podle mne je o něco jednodušší, protože nemá tolik možností. Třeba napodobit v něm věrně práci s SVN myslím nejde (nebo jen velmi krkolomně), takže by vás to aspoň nelákalo a naučil byste se to rovnou používat správně.

5165

Vývoj / Re:Proč bych měl přejít ze SVN na GIT? (vážně)

« kdy: 30. 07. 2014, 21:39:26 »

pan Novak chce slyset "SVN je lepsi nez GIT protoze X,Y", a to mu asi nikdo, kdo kdy pouzival SVN a pak GIT (nebo jiny DVCS) nerekne

Řekne, už se stalo:

Ale poradím vám jeden silný argument proti DVCS. Je to něco jiného, než SVN. Pracovat s Gitem jako by to bylo SVN je oproti SVN opruz. Místo update - merge - commit z SVN děláte s DVCS odložení změn (stash) - pull - rebase - unstash - commit - push. Některé kroky sice některé DVCS provedou automaticky, ale stejně člověk musí vědět, že se to dělá takhle. Takže přecházet na DVCS, aby to člověk dál používal jako SVN, to se nevyplatí.

5166

Vývoj / Re:Proč bych měl přejít ze SVN na GIT? (vážně)

« kdy: 30. 07. 2014, 21:16:02 »

Proc bych chtel v gitu casto commitovat? Neco jako autocommit by tam nebyl? svn commit neboli git push by mel byt oficialni akt publikovani svych zmen na verejnem serveru. Abych si pro sebe commitoval kazde uprdnuti, nechapu vyznam.

Dívejte se na to tak, že SVN a DVCS jsou úplně různé systémy. SVN je centrální úložiště zdrojových kódů, které má jako bonus udržování historie a dokonce i větvení. Prostě máte na jednom místě zdrojové kódy, a ty různí programátoři upravují - a SVN řeší, aby se při tom měnění moc nepoprali.
Naproti tomu DVCS je úložiště změn ve zdrojových kódech. Uděláte nějakou změnu a jako balíček ji uložíte do úložiště. DVCS řeší práci s těmito změnami - můžete je různě přesouvat, řadit je do větví apod.
V SVN děláte commit, když chcete svůj kód zpřístupnit ostatním. V DVCS commitujete, když uděláte jednu změnu. Význam? Můžete pak s tou změnou pracovat. Přesunout ji jinam, vyřadit jí, zařadit jí později.
Pokud nechcete pracovat se změnami a chcete jenom úložiště zdrojových kódů, použijte SVN.

5167

Vývoj / Re:Proč bych měl přejít ze SVN na GIT? (vážně)

« kdy: 30. 07. 2014, 18:54:51 »

Tisíce paralelních větví umožňují například ...

Ale to SVN umi taky a neni to problem.

Problém to není asi jak kde, každopádně z mého pohledu to Git umí podstatně lépe. Vlastně neznám SVN repository, kde by se tisíce paralelních větví používalo. Zato znám ze světa SVN případy "To by chtělo vytvořit branch. No tak já to radši nebudu commitovat, nechám si to u sebe na disku a pak to commitnu všechno najednou na konci". Nebo když je potřeba stejnou změnu promítnout do více větví, dělá se to ručně, protože SVN neumí commit aplikovat do jiné větve.

Jde jen o to, ze ty vetve jsou verejne a dostupne vsem (takze se neztrati, kdyz kolega jednoho dne neprijde do prace a nikdo dalsi nebude mit heslo k jeho PC)

Kolegovo repository může být zálohované na serveru nebo klidně sdílené ve veřejném nebo poloveřejném repository.

Hodně často narážím u evangelistů GITu na základní neznalosti práce v SVN. Je to úsměvné.

Nebo jsou to prostě jen uživatelé, kteří dříve používali SVN a pak začali používat i nějaký DVCS - a těžko vám budou vysvětlovat, že SVN taky větve umí a není to žádný problém, ale teprve s DVCS je používá často a rád.

Ale poradím vám jeden silný argument proti DVCS. Je to něco jiného, než SVN. Pracovat s Gitem jako by to bylo SVN je oproti SVN opruz. Místo update - merge - commit z SVN děláte s DVCS odložení změn (stash) - pull - rebase - unstash - commit - push. Některé kroky sice některé DVCS provedou automaticky, ale stejně člověk musí vědět, že se to dělá takhle. Takže přecházet na DVCS, aby to člověk dál používal jako SVN, to se nevyplatí.

Konečně podívej se na zdrojáky webkit/chromium. To je slepenec bez vnitřní organizace, ve kterém se prakticky nedá vyznat, na různých místech se střídají programátorské styly, někde dokonce i několik na jedné řádce.

To s verzovacím systémem nemá vůbec nic společného.

No spíš to souvisí s myšlenkou distribuovaného vývoje. Nikdy jsem tu myšlenku moc nepobral.

Jako že by bylo lepší, kdyby se všichni programátoři střídali u jednoho počítače? To jste asi nemyslel, že... Distribuovaný VCS s distribuovaným vývojem nijak nesouvisí, to "D" v "DVCS" znamená, že je distribuované úložiště zdrojáků, tedy celá historie projektu není jenom na jednom serveru, ale má ji každý vývojář u sebe. Třeba je pryč s notebookem, nemá připojení do internetu, a přesto může commitovat, procházet historii, vytvářet branche apod. Ale když se pak připojí k internetu, tak své repository sesynchronizuje s firemním, uvidí všechny nové změny a ostatní uvidí jeho změny, a nemusí nic mergovat nebo to jinak řešit.

5168

Server / Re:apache forwardovani ftp

« kdy: 30. 07. 2014, 18:27:02 »

Nepřipadá mi to jako dobrý nápad, použil bych raději nějaký FTP proxy server. Apache je HTTP server. Nějakou podporu FTP v sobě asi má, ale bůhví, co to dělá, a mod_proxy pro to nejspíš mít podporu nebude.

5169

Vývoj / Re:Proč bych měl přejít ze SVN na GIT? (vážně)

« kdy: 30. 07. 2014, 14:50:02 »

z mého pohledu práce na tisících paralelních branchí a velkých projektech obecně není podle mě dobrý styl

Tisíce paralelních větví umožňují například mít repository s kódem, který lze vždy přeložit, aniž by všichni museli mít nejaktuálnější verze všeho. Prostě bude několik větví, každá z nich samostatně půjde přeložit, ale např. ve větvi s optimalizací JavaScriptu budu mít původní vykreslovací jádro a nemusí mne trápit, že ve vedlejší větvi kolegové zrovna optimalizují vykreslovací jádro a ne všechny jejich pokusy jsou stabilní a vhodné pro situace, kdy mi má prohlížeč běžet déle než jednu sekundu.
Další možností je třeba to, že na jedné části kódu může pracovat víc lidí, a nemusí si upravené zdrojáky posílat e-mailem nebo předáváním svých částí zaplevelovat hlavní vývojovou větev.

Konečně podívej se na zdrojáky webkit/chromium. To je slepenec bez vnitřní organizace, ve kterém se prakticky nedá vyznat, na různých místech se střídají programátorské styly, někde dokonce i několik na jedné řádce.

To s verzovacím systémem nemá vůbec nic společného.

Pokud verzovací systém používáte jenom sám, viděl bych dvě výhody použití distribuovaného VCS oproti SVN: za prvé lepší podpora větví a řešení konfliktů, za druhé to, že celé repository máte v jednom adresáři a nepotřebujete žádný server.

5170

Vývoj / Re:Ako vznikol prvy kompilator?

« kdy: 30. 07. 2014, 09:07:31 »

JVM musí být povinně v jazyku produkujícím binárky, je použito C nebo C++.

Ve skutečnosti existují třeba implementace JVM v JavaScriptu, v Javě nebo přímo v hardwaru.

5171

Vývoj / Re:Staré zdrojáky - hříchy mládí

« kdy: 28. 07. 2014, 20:28:16 »

Nevidím důvod, proč by se k tomu autor měl vyjadřovat (neřekl bych, že má autor povinnost vyjádřit se ke všemu, co se objeví v diskusi pod článkem). A nevidím nic špatného na mazání komentářů, které s článkem nesouvisí - byť jsou třeba slušné. Copak mazání příspěvků mimo téma něčím porušuje nestrannost nebo věcnost? Právě naopak... Aspoň pak ta diskuse může mít alespoň nějakou minimální úroveň.
Ze strany redakce vidím jediný (ale dost vážný) problém v tom, že takový článek vůbec vyšel - jak má neznalý člověk poznat, zda jde o článek od někoho znalého, nebo o nešťastný pokus?

5172

Vývoj / Re:ZF vracia ARRAY namiesto vysledku

« kdy: 28. 07. 2014, 19:14:33 »

souhlasím, formulovat to přesněji je vždy namístě, ale příspěvek na který jsem reagoval já je opravdu "umachrovaný"

Ale bohužel je adekvátní reakcí na tazatele. Ten se nejdřív zeptá s největší pravděpodobností dřív, než by se pokusil v dokumentaci zjistit, co jím použitá funkce vlastně dělá (navíc nechá odpovídající hádat, v čem vlastně programuje, protože místo názvu použije zkratku, která může znamenat cokoli). Následně zprasí kód, aby mu to z pole záznamů vracelo jen první záznam, načež se začne rozčilovat, že mu to vrací jenom první záznam a to je přesně to, co nechtěl.
V tomto případě opravdu musí tazatel nejdřív pochopit, že programování nefunguje tak, že si vymyslím, co má program dělat, následně použiju libovolnou funkci a ona bude dělat to, co jsem chtěl - ale právě naopak, role programátora je právě v tom, že vymyslí, jak stávající funkce, které dělají něco přesně daného, poskládat tak, abych dostal kýžený výsledek.

5173

Hardware / Re:Kterou RAM přikoupit do notebooku?

« kdy: 28. 07. 2014, 16:37:39 »

Především si zjistěte, zda základní deska toho notebooku vůbec podporuje 8GB moduly. V dokumentaci k notebooku nebo základní desce byste měl najít, jaké moduly jsou podporované.

5174

Server / Re:OwnCloud pro produkční nasazení

« kdy: 27. 07. 2014, 15:07:08 »

Ja s Vami nediskutujem, preco chcem ulozisko ako je Dropbox.

Nejdřív si tedy asi budete muset rozmyslet, co vlastně chcete.
Jestli chcete úložiště jako Dropbox - tedy úložiště provozované v cloudu, který umožňuje pružně a automaticky reagovat na změny využití služby v čase, úložiště, které poskytuje API pro přístup aplikací třetím stranám, umožňuje spolupráci více subjektů a řešení přístupových práv, řeší verzování změn v souborech, poskytuje aplikace pro automatickou synchronizaci lokálních adresářů s úložištěm.
Nebo jestli chcete webovou aplikaci pro konverzi souborů, jejíž webové rozhraní by v něčem mohlo být podobné webovému rozhraní pro práci se soubory v Dropboxu.

Ano, toto vsetko chcem. Ulozisko zamerane na tlaciarov, ciastocne grafikov. API by som asi blokol. Preto som sa pytal na Owncloud/Seafile etc.

Ale mne nie je treba cloudovať. To porovnanie s Dropboxom nemusí až tak sedieť. ... Užívateľ nahraje PDF, klikne napr. na "konvertuj do CMYKu", na serveru sa spustí natívny kód a potom sa na úložisku sa objaví nový súbor cmyk.PDF. ... Diskutujúci sa sami presvedčili, že nechcem úložisko. Ja ako užívateľ chcem "Dropbox" a v ňom tlačítko na úpravu PDF. Alebo na konverziu JPEG do PDF. ... Vidim vyhody oproti up/downloadu. ... Moja naivná predstava je - nie, nie som informatik. Akú vybrať technológiu, aby som potom neľutoval.

Takže abych to shrnul. Chcete nějaké úložiště souborů, které poběží v cloudu, ale vlastně to cloud být nemusí. Má to být něco jako Dropbox, ale vlastně to jako Dropbox být nemá. Nechcete jenom upload, transformaci a download, protože chcete, aby uživatel jen uploadoval soubor, ten se na serveru transformoval a uživatel si ho zase stáhl. API pro přístup třetích stran potřebujete proto, abyste ho mohl zakázat. Nejste informatik a ptáte se na výběr technologie, a zároveň přesně víte, která technologie se má použít. Víte přesně, čemu má být vaše řešení podobné, ale ani jednou jste nenapsal, v čem by ta podobnost měla spočívat.
Já už jsem pár dotazů na webových fórech zodpověděl. Zúčastnil jsem se i mnoha diskusí, kde tazatel přesně věděl, jaká technologie a způsob řešení se má použít, akorát potřeboval poradit, jak ten jeho složitý šelmostroj vyrobit. Ty diskuse tak půl na půl vedly k tomu, že se podařilo tazatele přesvědčit, ať na svůj šelmostroj zapomene, popíše, jaký řeší problém - a pak vždy následovala rychlá odpověď s jednoduchým řešením, se kterým byl tazatel spokojen. V druhé polovině případů tazatel trval na tom, že bude vyrábět svůj šelmostroj a že jenom potřebuje poradit, jak to udělat. Posléze vynadal všem, kteří se mu snaží pomoci, že se málo snaží, a znechuceně odešel. Případně bývá později různě spatřován v diskusích s doplňujícími dotazy "mám hřebík a šroubovák, jak hřebík tím šroubovákem nejlépe zatlouci (kladivo v žádném případě použít nechci, neptejte se mne proč)", "sháním rovnák na vohejbák, kde se dá nejlevněji sehnat" apod. A koneckonců je to i moje práce analytika - zákazník zpravidla přijde s nějakou představou, jak něco udělat, takže je potřeba se s ním o tom chvíli bavit a společně formulovat, jaký vlastně řeší problém. Zákazník bývá velice často překvapen, když konečně zjistí, jaký problém vlastně chce řešit, přičemž řešení pak zpravidla bývá mnohem snazší než to, co původně požadoval (a často ani není z oblasti IT). Pravda je, že jiní tohle neřeší a s gustem zákazníkovi dodají (a nechají si zaplatit) přesně to, co na začátku požadoval. Z toho jsou pak všechny ty historky o IT projektech, které překračují rozpočet, nejsou hotové v termínu a ve výsledku jsou úplně k ničemu.

5175

Server / Re:OwnCloud pro produkční nasazení

« kdy: 27. 07. 2014, 12:01:43 »

Ja s Vami nediskutujem, preco chcem ulozisko ako je Dropbox.

Nejdřív si tedy asi budete muset rozmyslet, co vlastně chcete.
Jestli chcete úložiště jako Dropbox - tedy úložiště provozované v cloudu, který umožňuje pružně a automaticky reagovat na změny využití služby v čase, úložiště, které poskytuje API pro přístup aplikací třetím stranám, umožňuje spolupráci více subjektů a řešení přístupových práv, řeší verzování změn v souborech, poskytuje aplikace pro automatickou synchronizaci lokálních adresářů s úložištěm.
Nebo jestli chcete webovou aplikaci pro konverzi souborů, jejíž webové rozhraní by v něčem mohlo být podobné webovému rozhraní pro práci se soubory v Dropboxu.

Vidim vyhody oproti up/downloadu.

Dobře -  já jsem vyjmenoval pár podstatných vlastností Dropboxu. Které z nich jsou tedy ty vaše výhody?

Mam tak trochu pocit, ze ste trol.

To máte špatný pocit. Jenom máte zkreslenou představu o tom, co je Dropbox, zřejmě se vám líbí nějaká část jeho webového rozhraní, a mermomocí se snažíte do toho napasovat nějakou svou aplikaci. Já se vám pouze snažím pomoci v tom, abyste pro začátek zapomněl na Dropbox, nadefinoval si, co má vlastně vaše aplikace dělat, z toho odvodil, jak by se měla ovládat, a teprve pak si můžete vzpomenout na Dropbox a na to, že třeba GUI&UX práce se soubory ve webovém prohlížeči by mohlo být řešené podobně, jako vypadá GUI&UX Dropboxu.