Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Ondrej Nemecek

Stran: 1 ... 83 84 [85] 86 87 ... 90
1261
Software / Re:Změna $PATH shazuje shell
« kdy: 18. 09. 2015, 13:53:53 »
Je potřeba zjistit, která binárka se spouští. Třeba z výpisu procesů. Dále existuje příkaz which, který řekně, která binárka se bude spuštět (ještě než se spustí). Takže třeba

Kód: [Vybrat]
ondrej@test ~$ which sh
/usr/bin/sh

1262
O serveru Root.cz / Re:Nová podoba roota (beta)
« kdy: 17. 09. 2015, 10:53:26 »
Shrnuto:

  • změna loga je marketingové selhání
  • vizuélně je to agresivní, navíc to nutí všechen obsah stejnou měrou
  • takže je nutné odlišit hlavní obsah od doprovodného obsahu a promo obsahu - aby to nebylo na jedné úrovni (odlišit barvou pozadí?)

Jinak souhlasím, že návštěvníci roota by vesměs akceptovali čistě textové stránky a lépe by se v nich i orientovali, ale chápu, že by to nesplnilo obchodní cíle. Takže nic.

1263
Vývoj / Re:Jak se postavit k nekvalitnímu projektu?
« kdy: 04. 09. 2015, 23:06:17 »
Predevsim u toho prepisu nejsou k dizpozici zadani, podle kterych to puvodne vznikalo, a nikdo si uz nepamatuje, co vsechno se vlastne chtelo aby to umelo. Osobne sem se ucastnil, a osobne sem prepisovatele predem varoval, ze nikdo nevi, co vsechno ta vec vlastne dela. Vysledek byl v souladu s ocekavanim (tedy, mym ocekavanim, managori vazne verili, ze bude fungovat) - misto v unoru se to zprovoznilo v lednu.

Jenže cílem nemusí být realizovat to samé - cílem může být realizovat jen to, co se používá a realizovat to lépe.

1264
Vývoj / Re:Jak se postavit k nekvalitnímu projektu?
« kdy: 04. 09. 2015, 16:49:03 »
Jojo, nové začátky jsou prostě osvobozující - člověk odhazuje tíživou karmu projektu a jde vstříc novým světlým zítřkům. Nikde ale není zaručeno, že neskončí stajně jako předtím. Nicméně úkolem všech patternů je zařídit, aby ta karma zůstala pokud možno čistá a aby bylo co nejmenší puzení k přepisu kódu...

1265
Vývoj / Re:Jak se postavit k nekvalitnímu projektu?
« kdy: 04. 09. 2015, 15:13:20 »
Přepis aplikace má tu výhodu, že máte k dispozici údaje, které nebyly původně k dispozici. Nevýhodu máte v tom, že musíte znova realizovat zadání zpravidla za několik let, což je obvykle víc práce, než se v evangelizačním nadšení zprvu zdá. A stále tam zůstává problém skrých předpokladů - use-casů, které se sice používají, ale zákazník si to vůbec neuvědomuje.

Typické reakce jsou: Ta nová verze je hrozná, nejde tam udělat XY a zrovna tohle v původní verzi fungovalo skvěle. Cože, vy jste něvěděl, že to takto používáme?? No ale za to mi nemůžeme, přece jsme nechtěli, abyste nějakou funkčnost rušil, mysleli jsme že to bude fungovat jako dřív a že si to jen nějak uvnitř uzpůsobíte aby se v tom vám lépe programovalo a aby to bylo rychlejší...

K principu DRY: Někdy je lepší se opakovat a zachovat ortogonalitu, než se za každou cenu neopakovat a vytvořit přebujelou hiearchii tříd nebo do sebe zaklesnutých pomocných modulů, které rádoby dělají tu věc, které se nemá opakovat, ale jsou špatně navržené. Takže než vytvořit nezvládnutou abstrakci, je lepší to psát jednoduše. V tom dost pomůže prototypování - otestuje se, zda zvolená architektura zachycuje reálné potřeby.

Kvalitu si představuje programátor typicky jako elegantní návrh (a možná i jako odolnost vůči chybám), uživatel požaduje hlavně srozumitelné gui no a manager to chce zítra :-)

1266
Vývoj / Re:Jak se postavit k nekvalitnímu projektu?
« kdy: 04. 09. 2015, 09:57:59 »
První otázka zákazníka bude: Kolik by to stálo a co se refaktorací rozbije? Co tím získám?

Z toho vyplývá, jak se postavit k projektu: Musítě spočítat, kolik vyjde údržba a implementace nových funkčností za stávajícího stavu a kolik po refaktoraci. Náklady musí vyjít stejně nebo ve prospěch refaktorace. Zhodnoťte si to sám a pak prezentujte zákazníkovi. Náklady musí vyjít ve prospěch refaktorace, jinak do toho zákazník nebude chtít. Dost zásadní taky je, zda se dá refaktorovat postupně nebo zda se to musí udělat (a zaplatit) naráz. A musíte zákazníka přesvědčit, že do provozu se to nasadí hladce a bez chyb. Pokud máte podobný případ už za sebou, dokladujte to na příkladech. Uvažujte taky, jaký provoz zvládne aplikace obsloužit. Pokud bude stávající implementaci brzo docházet dech, bude výkonové zlepšení žádoucí a bude to podstatný argument pro uvolnění financí.

Jinak každý má jinou minimální úroveň projektu, do kterého by šel. Že něco vrací jen http 200 nemusí být problém, podstatnější je, jestli to API chyby ošetřuje a zda ošetřuje všechny chybové stavy. Minimálně při výpadku serveru se tam mohou objevit jiné kódy a ty musí být na klientovi ošetřené. Při refaktoraci bych využil nějaký hotový protokol, vzdálené volání procedur nebo něco podobného, pokud to projekt umožňuje.

1267
Vývoj / Re:Scala vs. Java 8.
« kdy: 31. 08. 2015, 20:11:11 »
Vlastnosti Scaly ocení člověk, který vidí trochu do hloubky. Pro průměrného javistu je obtížně srozumitelná - mluvím z vlastní zkušenosti :-)

Ale na druhou stranu je to šance, jak se toho dost přiučit, takže bych to nevzdával hned na začátku. Taky proto, že jazyky nad jvm mají podle mě budoucnost, protože spojují to, co je známé a už funguje (jvm a knihovny) a přidávají k tomu pokrokové prvky (nový jazyk).

1268
Vývoj / Re:Native queries (aneb databáze a OOP)
« kdy: 31. 08. 2015, 12:09:08 »
Díky, nejdřív jsem myslel, že posíláš svojí diplomku :-) ale vypadá to, že to psal někdo jiný. Naštěstí to je psané docela srozumitelně.

Koukal jsem ještě na LINQ a jestli to je integrální součást C# tak to je docela frajeřina.

1269
Vývoj / Re:Native queries (aneb databáze a OOP)
« kdy: 30. 08. 2015, 16:18:18 »
"Textová" syntax nikdy není NQ. NQ vůbec nesouvisí s bajtkódem (ani s Javou), jen to prostě v Javě jinak než přes bajtkód nejde.
ORM je způsob ukládání objektů do relační databáze. S dotazy nijak nesouvisí. Perzistence je jiná vrstva (buď OODB nebo ORM) někde pod OO rozhraním.
Suma sumarum SODA je primitivní překlad do OQL nebo něčeho podobného, kdežto NQ je zápis přímo v jazyce (proto "native").

Dobře, jak vznikne z NQ ten SQL?

OQL, ne SQL. To je právě ta magie. V Javě z bajtkódu, jinak se musí nějak poskládat AST. Když jsem si s tím hrál naposledy v C++, microsoftí překladač zkolaboval a v clangu jsem tak našel bug v linkeru. Swift to v poslední verzi zvládá hezky (operátor se dá přetížit několikrát s různými návratovými hodnotami a automatická inference typu udělá z "x == 100" buď bool nebo predikát podle místa použití - tak má ostatně OOP vypadat), jen ta implicitní konverze chybí.

A NQ interpretuje tedy libovolný nativní kód? To by byl ten principielní rozdíl oproti v SODA, kde jsou jen předpřipravené metody....

NQ jsou v podstatě záležitost compile time (v ideálním případě). SODA je záležitost run time.

Aha, v tom případě si nedokážu představit, jak NQ funguje. To jako analyzuju bytekód (v případě javy) a nahradím v něm nativní zápis dotazu za něco jiného? Vygeneruju kód na míru mému nativnímu dotazu?

1270
Vývoj / Re:Native queries (aneb databáze a OOP)
« kdy: 30. 08. 2015, 16:07:04 »
Když se SQL generuje z bajtkódu v runtime, je to NQ, ale když se generuje za běhu programu, je to SODA? Trochu se to komplikuje...

Ehm, není to přesně to samé? Nebo jde jen o ten bytekód (to nezní moc obecně)?

Myslel jsem to tak, že pro NQ je potřeba nějaká manipulace s batekódem (po kompilaci) anebo podpora v runtime (která s bajtkódem něco dělá za běhu), kdežto SODA jen jednoduše pospojuje řetězce a hotovo.



1271
Vývoj / Re:Native queries (aneb databáze a OOP)
« kdy: 30. 08. 2015, 15:55:33 »
"Textová" syntax nikdy není NQ. NQ vůbec nesouvisí s bajtkódem (ani s Javou), jen to prostě v Javě jinak než přes bajtkód nejde.
ORM je způsob ukládání objektů do relační databáze. S dotazy nijak nesouvisí. Perzistence je jiná vrstva (buď OODB nebo ORM) někde pod OO rozhraním.
Suma sumarum SODA je primitivní překlad do OQL nebo něčeho podobného, kdežto NQ je zápis přímo v jazyce (proto "native").

Dobře, jak vznikne z NQ ten SQL?

1272
Vývoj / Re:Native queries (aneb databáze a OOP)
« kdy: 30. 08. 2015, 15:05:32 »
Pleteš si (stejně jako perceptron) NQ a SODA.

Prosím tedy vysvětlit, co je NQ a SODA - v čem tkví rozdíl. A jak si v tom stojí ORM.

řípadně i odkaz na zdroje - nějak se mi to nedaří najít.

Jasně, díky, už jsem se toho taky dovtípil - v NQ se ty podmínky zapisují pomocí java kódu (vezměme jako příklad javu), takže to vypadá, jakoby se podmínka vyhodnocovala přímo v javě (kde se ve skutečnosti vyhodnocuje to je jiná otázka, zřejmě se z bajtkódu vyganeruje sql). Například zde http://www.java-objects-database.com/jodb-general-section/help/native-query.html je příklad, kde se podmínka zapíše jako

Kód: [Vybrat]
return pilot.getPoints() > 100 && pilot.getPoints() < 500 ;

V SODA se uvádí název sloupce, takže by tam bylo něco jako

Kód: [Vybrat]
Query.from(Pilot.class).where("points > ?", 100).and("points < ?", 500).selectAll();

Jenže třeba Dari http://www.dariframework.org/ překládá textovou SODA-like syntax na predikáty http://www.dariframework.org/javadocs/com/psddev/dari/db/PredicateParser.html Otázka je, zda jde ve výsledku o NQ nebo SODA.

Která vrstva rozhoduje, jestli jde o NQ nebo SODA? Když se SQL generuje z bajtkódu v runtime, je to NQ, ale když se generuje za běhu programu, je to SODA? Trochu se to komplikuje...

A za ORM byste teda považoval jen to, jakým způsobem se zabalí výsledek SQL dotazu do objektů?

1273
Vývoj / Re:Native queries (aneb databáze a OOP)
« kdy: 30. 08. 2015, 14:32:28 »
Pleteš si (stejně jako perceptron) NQ a SODA.

Prosím tedy vysvětlit, co je NQ a SODA - v čem tkví rozdíl. A jak si v tom stojí ORM.

řípadně i odkaz na zdroje - nějak se mi to nedaří najít.

1274
Vývoj / Re:Programovaci jazyk budoucnosti
« kdy: 20. 08. 2015, 20:37:52 »
dekuji za rady urcite budu muset zacit s necim mnohem jednodussim, na tohle nemam je to spousta pojmu ktere mi jsou naprosto cizi ...

jsem asi ten posledni kdo by mel filozofovat ale neda mi to, pripada mi ze pokud se nezmeni paradigma, je to furt o tom, ze netrenovany clovek "od prirody" ma nejaky mentalni model, ktery se proste s pocitacem nedomluvi

mym ukolem je natrenovat jiste dovednosti tj. zmenit svuj mentalni model cili jakoby ja kracim smerem k pocitaci

co to otocit a rici si, netrenovany clovek ma tendenci myslet takhle a takhle takze programovaci jazyk musi respektovat tyto intuitivni prirozene myslenkove konstrukce cloveka od prirody, tedy pocitac kraci smerem k cloveku ?

treba tady to testovali jak to neprogramatorum mysli

http://www.cs.cmu.edu/~pane/ftp/PaneRatanamahatanaMyers2001.pdf

je to podobne jako user experience a GUI,  ma  se clovek ucit kde kam kliknout nebo naopak se ma pozorovat co by kde clovek hledal a mackal (nejlepe male deti treba kdyz poprve dostanou doruky tablet nebo pc s mysi) a tomu prizpusobit rozhrani ? (intuitivnost, napr. mac os x )

mne jako neprogramatorovi ktery nema ten spravny mentalni model momentalne pripada jako nejschudnejsi "naucit se spravne ptat strycka googla" tak abych to co opravdu minim svym dotazem dostal jako odpoved na 1. miste (I am feeling lucky).

Budoucnost by pak vlastne mohla byt nejaka grandiozni databaze znalosti, pres kterou by se dotazovalo (clovek by se musel naucit jak se spravne ptat - vlastne opet zmena mentalniho modelu jako programator-neprogramator), nejspis typu decision trees at uz bych se ptal ja a stroj odpovidal nebo obracene) jako se v zarodku trochu nesmele dotazuje treba tady clovek ktery chce jednoucelove takove dotazovaci systemy tvorit resp. udelat platforumu pro jejich tvorbu

https://www.reddit.com/r/AskProgramming/comments/3hi33t/what_kind_of_programmer_do_i_need_to_create_a_web/

Jo, to s tím mentálním modelem souhlasí. Jenže mentální model má dokonce i každý programátor jiný (stačí si přečíst nějaké jazykové flamy v diskuzi zde na root.cz). A u lidí obecně se liší ještě mnohem více. Roli hraje  pohlaví, profese, věk, zkušenosti, temperament, jazykové prostředí atd atd. Takže udělat obecný systém je nesmírně obtížné. Vždyť si vezměte si, jak je obtížné, abyste se vy sám dorozuměl s kolegy nebo blízkými - a to jste přitom sám velmi dokonalým učícím se systémem se slušnou databází zkušeností :-D Takže obecný systém přístupný každému je protimluv, protože jednoduše každý mluví „jinou řečí“, myslí jinak a je jiný. Co lze udělat, je jednoduchý neobecný systém, který bude mít sice menší bariéru pro laiky, ale který zvládně jen omezenou sadu úloh, anebo naopak obecnější složitý systém určený pro specialisty, který ovšem zvládne velmi široké spektrum úloh. Zástupce obou případů se najde dostatek.

K tomu bych doplnil, že pokud vám nejde programování, nijak se tím netrapte. On ten „počítačový mentální model“ dost deformuje myšlení, protože je  jednostranný (přečtěte si knihu Digitální demence http://www.kosmas.cz/knihy/186714/digitalni-demence/). Třeba máte jiný talent... Práci, které nás stroje zbavili, bychom měli věnovat taky porozumění lidem a lidství vůbec, protože tam jsme jako lidé stále nezastupitelní. Samozřejmě je potřeba udržovat stroje v chodu a vyvíjet je, může to být i velmi zajímavé, ale... ...jsou i jiné věci. Stroj je jen stroj a představa, že vznikne „systém na všechno“ je pouhou záměnou reality za virtualitu. Ten systém tu totiž už je - je to svět okolo nás.

1275
Vývoj / Re:PHP knihovna mPDF - použití SVG
« kdy: 20. 08. 2015, 19:53:39 »
Ahoj,
čelím problému...v php kodu používám knihovnu na generovani PDF...konkretně mPDF
v ní se snažím do PDF dostat SVG neobvyklím způsobem.
zachycení SVG jako string
Kód: [Vybrat]
$svg = $_POST['structureSVG'];
$svg_pdf = str_replace('"', '\'', $svg); //change " to '
kontrola co se dostane do proměné:
Kód: [Vybrat]
var_dump($svg_pdf);
                                //vypíše string obsahující xml(svg)
<svg>...</svg>
tedy mohu si byt jistý že jsem zachytil co jsem chtěl a správně. Nyní tuto proměnou insertnu do kódu, který bude zpracován mPDF:
Kód: [Vybrat]
$html = " <div> $svg_pdf </div> ";
$mpdf -> WriteHTML($html);
$mpdf -> Output('pdf/test_svg.pdf', 'I');

bohužel tímto způsobem se mi nedaří svg vyrenderovat do PDF
chtěl jsem se zaregistrovat na foru mPDF, ale registrace se mi nepodařila ani s několika různých emailů

díky za jakoukoliv pomoc

Knihovna mPDF není žádný zázrak, opravdu umí embedded svg? Píše se tam, že umí „SVG images“, ale to může taky znamenat, že umí svg vložené jako <img>. Zkuste tuto variantu, pokud můžete. A pokud byste to svg navíc styloval pomocí css, může být problém i tam.

Pokud byste to s mPDF nerozběhal, můžete zauvažovat, zda by problém s generováním pdf nevyřešil lépe PhantomJS. Uděláte běžnou html stránku a WebKit vám z ní vyplyvne pdf. Imho je to mnohem snažšší na ladění (ladíte ve WebKit prohlížeči), vyžaduje to ovšem instalaci na server.

Stran: 1 ... 83 84 [85] 86 87 ... 90