[django-cs] Překlad modelů v Django

[Jan Walter]

Ahoj,

chtěl bych se zeptat, jestli máte praktické zkušenosti s lokalizací
případně internacionalizací dat v modelech, konkrétně zda používáte nějakou
knihovnu, která s tím významně pomáhá (a ideálně je připravena např. na
stromovou strukturu via django-mptt).

Narazil jsem na supr intro do tématu
https://www.youtube.com/watch?v=vdbpinOmMeo, v každém případě špatné,
srovnávací, a nakonec i ty dobré zkušenosti jsou k nezaplacení.

Díky,
John

-- 
-- 
E-mailová skupina django-cs@googlegroups.com
Správa: http://groups.google.cz/group/django-cs
--- 
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny django-cs 
ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete 
e-mail na adresu django-cs+unsubscr...@googlegroups.com.
Chcete-li zobrazit tuto diskusi na webu, navštivte 
https://groups.google.com/d/msgid/django-cs/CAK-vJU%3DZjQi3fU4KfU7iSqZKbPujiczhegs%3DCzN5jY90JWchGw%40mail.gmail.com.

Re: [django-cs] Re: Hosting Django aplikací

[Jan Walter]

My máme dobrou zkušenost (spolehlivost, mimořádný cena/výkon) s contabo.com.

On Wed, Nov 9, 2022, 13:00 MirekZv  wrote:

> Já jsem používal Forpsi a myslím, že to šlapalo hezky.
> Samozřejmě doba, kdy 20G s Linux image byla za 35 Kč na měsíc, je pryč,
> ale myslím, že kolem těch asi 85 Kč je to pořád dost přijatelné.
>
> Dne pátek 21. ledna 2022 v 18:04:26 UTC+1 uživatel stanisl...@gmail.com
> napsal:
>
>> Zdravím,
>>
>> chtěl bych se zeptat, kde hostujete své Django aplikace/weby? Osobně
>> používám VPSfree hosting. Nemám problém si sám spravovat VPSka, ale v
>> poslední době mi připadají servery takové... líné, pomalu reagující. Když
>> stejnou aplikaci pustím na notebooku či VPSku na serveru co mám doma,
>> dostanu rapidně jinou odezvu.
>>
>> Předem díky za tipy, Standa
>>
>>
>> --
> --
> E-mailová skupina django-cs@googlegroups.com
> Správa: http://groups.google.cz/group/django-cs
> ---
> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
> „django-cs“ ve Skupinách Google.
> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny,
> zašlete e-mail na adresu django-cs+unsubscr...@googlegroups.com.
> Chcete-li tuto diskusi zobrazit na webu, navštivte
> https://groups.google.com/d/msgid/django-cs/cff63637-669a-4187-a206-e2de257f9d48n%40googlegroups.com
> 
> .
>

-- 
-- 
E-mailová skupina django-cs@googlegroups.com
Správa: http://groups.google.cz/group/django-cs
--- 
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny django-cs 
ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete 
e-mail na adresu django-cs+unsubscr...@googlegroups.com.
Chcete-li zobrazit tuto diskusi na webu, navštivte 
https://groups.google.com/d/msgid/django-cs/CAK-vJU%3Dv_JE8FW4T9_qhw8rw5xxW%2B5G%3DHjm8i78WLvqGNKMN1g%40mail.gmail.com.

Re: [django-cs] Jak žít s MySQL/PostgreSQL snadno a zálohovaně?

[Jan Walter]

@starenka umis pres dbshell i zalohu?

On Fri, 26 Feb 2021, 09:26 Vladimir Linhart, 
wrote:

> Ja bych ten prechod na velkou DB odkladal dokud to fakt nebudes potrebovat
> - db na jinem stroji
> - pomala sqlite
> - problemy se zapisem
> - chces vyuzit featury postgresu
>
> Taky pouzivam sqlite na spouste mensich projektu a to pohodli/cas ma
> velkou cenu.
>
> On Fri, Feb 26, 2021 at 9:17 AM starenka .  wrote:
> >
> > V 99% pres 'manage.py dbshell'
> >
> > On Fri, Feb 26, 2021, 08:28 Stanislav Vasko 
> wrote:
> >>
> >> Díky všem za reakci. Osobně jsem se na produkci také nikdy nevracel,
> ale tak ještě to důležité:
> >>
> >> DB spravujete přes DB aplikaci, extra, nebo jsou v Django na to
> příkazy, jako jsem uváděl níže?
> >>
> >> Standa
> >>
> >>
> >> On 26 February 2021 at 1:24:18, starenka . (staren...@gmail.com) wrote:
> >>
> >> Messa: session muze mit x backendu, samorejme se cachuje atd. bylo mi
> jasny uz pri psani, ze budes kejhat :)
> >>
> >> Slo o zdurazneni pointu, ze sqlite imo na produkci neceho min nez toy
> projektu nema co delat...
> >>
> >> On Fri, Feb 26, 2021, 01:11 Petr Messner 
> wrote:
> >>>
> >>> pá 26. 2. 2021 v 0:51 odesílatel starenka . 
> napsal:
> 
>  Souhlasim s Honou a este bych rad upozornil, ze sqlite (pokud je mi
> znamo) nepodoruje (narozdil od cteni) simultani zapis a tedy kdyz do ni
> jeden worker/proces zapisuje, je databaze locknuta na zapis a ty cekaji ve
> fronte (cteni je behem zapisu ok). Vzhledem k tomu, ze se do db zapisuje i
> "mimo tvuj kod" (napr. session), neni to asi obecne idealni reseni pro
> vytizenejsi appky.
> >>>
> >>>
> >>>
> >>> Je to v praxi (u menších aplikací) opravdu problém? I ve WAL módu?
> >>> https://sqlite.org/wal.html
> >>>
> >>> Jestli i obyčejný read-only přístup do session znamená nějaký zápis do
> db, tak to možná není ideální a dá se to řešit několika způsoby. Ale dobrý
> point, někdy je třeba na toto myslet.
> >>>
> >>> Petr M.
> >>>
> >>>
> >>> --
> >>> --
> >>> E-mailová skupina django-cs@googlegroups.com
> >>> Správa: http://groups.google.cz/group/django-cs
> >>> ---
> >>> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
> „django-cs“ ve Skupinách Google.
> >>> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny,
> zašlete e-mail na adresu django-cs+unsubscr...@googlegroups.com.
> >>> Chcete-li tuto diskusi zobrazit na webu, navštivte
> https://groups.google.com/d/msgid/django-cs/CAK9Q5BTYd-eumm-7pjVWFctwz9Rrpab0LpfMMBuwiophq-2-UA%40mail.gmail.com
> .
> >>
> >> --
> >> --
> >> E-mailová skupina django-cs@googlegroups.com
> >> Správa: http://groups.google.cz/group/django-cs
> >> ---
> >> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
> „django-cs“ ve Skupinách Google.
> >> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny,
> zašlete e-mail na adresu django-cs+unsubscr...@googlegroups.com.
> >> Chcete-li tuto diskusi zobrazit na webu, navštivte
> https://groups.google.com/d/msgid/django-cs/CA%2B7MNVpFKOgPSqyj1VbndGeFmUaXT67xt6QCfT0aOgfWHDuqfw%40mail.gmail.com
> .
> >
> > --
> > --
> > E-mailová skupina django-cs@googlegroups.com
> > Správa: http://groups.google.cz/group/django-cs
> > ---
> > Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
> „django-cs“ ve Skupinách Google.
> > Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny,
> zašlete e-mail na adresu django-cs+unsubscr...@googlegroups.com.
> > Chcete-li tuto diskusi zobrazit na webu, navštivte
> https://groups.google.com/d/msgid/django-cs/CA%2B7MNVqBUp2d59hFG1oE67R7X69H2ypGGU2xghAVkbNg8rzEuA%40mail.gmail.com
> .
>
> --
> --
> E-mailová skupina django-cs@googlegroups.com
> Správa: http://groups.google.cz/group/django-cs
> ---
> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
> django-cs ve Skupinách Google.
> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny,
> zašlete e-mail na adresu django-cs+unsubscr...@googlegroups.com.
> Chcete-li zobrazit tuto diskusi na webu, navštivte
> https://groups.google.com/d/msgid/django-cs/CAFrZPmRsgJfTPOvuHCVdyQWqy%2B%2B-sE-8TN8%2Bgjhr1HOnNaKMZw%40mail.gmail.com
> .
>

-- 
-- 
E-mailová skupina django-cs@googlegroups.com
Správa: http://groups.google.cz/group/django-cs
--- 
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny django-cs 
ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete 
e-mail na adresu django-cs+unsubscr...@googlegroups.com.
Chcete-li zobrazit tuto diskusi na webu, navštivte 
https://groups.google.com/d/msgid/django-cs/CAK-vJU%3Duev%3D254F8%2BwmJXKXsLmNxsnQsT7n6Mma%2B%3DLhdSAXSOg%40mail.gmail.com.

Re: [django-cs] Jak žít s MySQL/PostgreSQL snadno a zálohovaně?

[Jan Walter]

Na zalohy doporucuju pg_dump a pg_restore, nativni prikazy postgresu,
reknes si cilovy format (napr. komprese), zda mazat data, vytvaret objekty
atp. V zakladu jednoduchy, komplexni zaloha db se vsim vsudy.

Smazani a vytvoreni db take tak (createdb, dropdb, nebo obecnym psql, kam
posles query, co potrebujes).

On Fri, 26 Feb 2021, 08:28 Stanislav Vasko, 
wrote:

> Díky všem za reakci. Osobně jsem se na produkci také nikdy nevracel, ale
> tak ještě to důležité:
>
> DB spravujete přes DB aplikaci, extra, nebo jsou v Django na to příkazy,
> jako jsem uváděl níže?
>
> Standa
>
>
> On 26 February 2021 at 1:24:18, starenka . (staren...@gmail.com) wrote:
>
> Messa: session muze mit x backendu, samorejme se cachuje atd. bylo mi
> jasny uz pri psani, ze budes kejhat :)
>
> Slo o zdurazneni pointu, ze sqlite imo na produkci neceho min nez toy
> projektu nema co delat...
>
> On Fri, Feb 26, 2021, 01:11 Petr Messner  wrote:
>
>> pá 26. 2. 2021 v 0:51 odesílatel starenka .  napsal:
>>
>>> Souhlasim s Honou a este bych rad upozornil, ze sqlite (pokud je mi
>>> znamo) nepodoruje (narozdil od cteni) simultani zapis a tedy kdyz do ni
>>> jeden worker/proces zapisuje, je databaze locknuta na zapis a ty cekaji ve
>>> fronte (cteni je behem zapisu ok). Vzhledem k tomu, ze se do db zapisuje i
>>> "mimo tvuj kod" (napr. session), neni to asi obecne idealni reseni pro
>>> vytizenejsi appky.
>>>
>>
>>
>> Je to v praxi (u menších aplikací) opravdu problém? I ve WAL módu?
>> https://sqlite.org/wal.html
>>
>> Jestli i obyčejný read-only přístup do session znamená nějaký zápis do
>> db, tak to možná není ideální a dá se to řešit několika způsoby. Ale dobrý
>> point, někdy je třeba na toto myslet.
>>
>> Petr M.
>>
>>>
>> --
>> --
>> E-mailová skupina django-cs@googlegroups.com
>> Správa: http://groups.google.cz/group/django-cs
>> ---
>> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
>> „django-cs“ ve Skupinách Google.
>> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny,
>> zašlete e-mail na adresu django-cs+unsubscr...@googlegroups.com.
>> Chcete-li tuto diskusi zobrazit na webu, navštivte
>> https://groups.google.com/d/msgid/django-cs/CAK9Q5BTYd-eumm-7pjVWFctwz9Rrpab0LpfMMBuwiophq-2-UA%40mail.gmail.com
>> 
>> .
>>
> --
> --
> E-mailová skupina django-cs@googlegroups.com
> Správa: http://groups.google.cz/group/django-cs
> ---
> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
> „django-cs“ ve Skupinách Google.
> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny,
> zašlete e-mail na adresu django-cs+unsubscr...@googlegroups.com.
> Chcete-li tuto diskusi zobrazit na webu, navštivte
> https://groups.google.com/d/msgid/django-cs/CA%2B7MNVpFKOgPSqyj1VbndGeFmUaXT67xt6QCfT0aOgfWHDuqfw%40mail.gmail.com
> 
> .
>
> --
> --
> E-mailová skupina django-cs@googlegroups.com
> Správa: http://groups.google.cz/group/django-cs
> ---
> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
> „django-cs“ ve Skupinách Google.
> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny,
> zašlete e-mail na adresu django-cs+unsubscr...@googlegroups.com.
> Chcete-li tuto diskusi zobrazit na webu, navštivte
> https://groups.google.com/d/msgid/django-cs/CAMD1ck8UOOnkpzNQy%2BKiwniegg4-%3DbHBJhgQofXCjaOhwPYgtQ%40mail.gmail.com
> 
> .
>

-- 
-- 
E-mailová skupina django-cs@googlegroups.com
Správa: http://groups.google.cz/group/django-cs
--- 
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny django-cs 
ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete 
e-mail na adresu django-cs+unsubscr...@googlegroups.com.
Chcete-li zobrazit tuto diskusi na webu, navštivte 
https://groups.google.com/d/msgid/django-cs/CAK-vJUk08gVrcZCt_UQToP9L9e8nO%3Ddk-ro0Tycv3Ee1kUek3Q%40mail.gmail.com.

Re: [django-cs] Django + Vue = VL? Nebo je to úplně jinak?

[Jan Walter]

Mrkni https://github.com/jnwltr/swagger-angular-generator. Obdobnych
knihoven najdes urcite vic. Lisit se budou estetikou a funkcnosti (vc.
cilovyho frameworku), co z toho leze.

Nejde jen o to, ze to setri, jak rikas, nudnou praci, ale hlavne to vytvari
pevnou vazbu mezi FE a BE, cili to vychytava mozny chyby typicky pri
zmenach BE (nepasujici FE ani nebuildnes).

On Tue, 23 Feb 2021, 18:03 mk,  wrote:

> Kdysi jsem delal nejaky demo projekt s https://intercoolerjs.org/ a byla
> to docela pohoda. Intercooler, se zda, mezitim zmutoval do
> https://htmx.org/
>
> Dne úterý 23. února 2021 v 12:03:19 UTC+1 uživatel Honza Javorek napsal:
>
>> Podle mě ten hotwire muže fungovat dobře, pokud mas tým na jedne lodi a
>> chcete to tak dělat, nebo si to děláš sám pro sebe. A pokud nechceš silně
>> oddělovat ty role do sila “frontendist” a “backendisti”, ale mas lidi,
>> kteří rozumí víc celé věci. Ale přímou zkušenost nemám.
>>
>> Jinak je dnes trh zblaznen do SPA, takže jakmile chceš frontend zadat
>> atd., budou na tebe s timhle koukat jak na blázna, protože přece standard
>> je React nebo Vue a 3000 npm balíčku k tomu a bez toho “si spad z višně ne,
>> dědku”? Nebo aspoň tak mi to přijde :D
>>
>> S tím API, podle mě REST, tak jak ho provozovala většina, bylo “my
>> backendisti ti tady dáváme co ti dáváme a ty frontendisto se s tím smiř” (v
>> Apiary jsme se snažili, aby probíhal dialog, ale asi to bylo nemožné to po
>> lidech chtít). Takže frontendisti si na truc přišli s GraphQL a řekli “my
>> frontendisti chceme odpovědi tady na tyhle queries a ty backendisto se s
>> tím smiř”. Tedy ten trend je teď takový, že na backendu vystavis GraphQL a
>> frontendista si na tom už pak zvládne postavit co potřebuje, nemusíš se
>> trápit s REST API na míru. Jestli je GraphQL vhodné i jako public API “pro
>> stroje” (tedy ono je to VŽDY pro lidi, na to je dobré myslet, ale v tomto
>> případě jsou to asi backenďáci skrze nějakou integraci), o tom jsem se
>> zatím úplně nerozhodl. Podle mě to rozhoduje především tooling - většina
>> toho je v JS a jakmile chceš takové API konzumovat v Pythonu, už to hodně
>> skripalo (dnes lepší, jsem nedávno zjistil, vyvíjí se to) a nechci vědět,
>> co by na to řekli Javisti v bance (ale třeba se mýlím a Java support pro
>> konzumaci GraphQL - ne tvorbu backendu, pozor - je v pohodě). Takže někdy
>> lidi udělají GraphQL pro frontenďáky a pak vedle toho ještě nutné minimum
>> REST API pro externí integraci.
>>
>> Tož tolik mých 5 haléřů.
>>
>> HJ
>>
>>
>> On Tue 23. 2. 2021 at 11:22, Vladimír Macek  wrote:
>>
>>> Hotwire vypadá pro nás staromilce zajímavě. Ale nezruší se tím Martinem
>>> popisované výhody? Hranice působnosti rolí v týmu, dané a dokumentované
>>> rozhraní světů, rozdělení BE do komponent...
>>>
>>> Když by tu byl datově orientovaný projekt, u kterýho se člověk zaměřuje
>>> na
>>> komplikovanější backend, frontend by rád někomu zadal a zároveň by
>>> chtěl,
>>> aby k datům backendu mohly i stroje, služby...
>>>
>>> Jsem v té situaci a zajímalo by mě, zda skutečně máte někdo hlubší
>>> zkušenost s tím, že vyrábíte API pro stroje i FE zároveň. Chápu, že
>>> stroj i
>>> FE budou mít nějaké extra buřtíky, které ten druhý nevyužije. Zůstává
>>> ale
>>> BE API jednotné?
>>>
>>> Pozitivní náznaky v diskusi jsou, ale vyzkoušel někdo skutečně tento
>>> princip hlouběji? Pokud ano, co jste na to použili a jste s tou volbou
>>> spokojení? (Honzovu reakci jsem zachytil a chápu ji jako pozitivní hlas.)
>>>
>>> Jak vypadá třeba po 6 nebo 12 život s tím, že FEčkaři mají nějaké
>>> požadavky, strojové API si vyžaduje možná něco trošku jiného...?
>>>
>>> Netvrdím, že nemám představu o cestě a že nemám žádné API za sebou. :-)
>>> Ale
>>> stejně jako Standa nechci, aby mi unikla zajímavá volba na základě
>>> zkušeností.
>>>
>>> Díky,
>>>
>>> Vláďa Macek | +420 608 978 164 <+420%20608%20978%20164>
>>>
>>>
>>> On 23. 02. 21 10:08, Honza Javorek wrote:
>>> > Uvažoval nebo použil někdo
>>> > https://hotwire.dev/, tedy staromilecký klasický přístup kdy z Djanga
>>> > generuji HTML šablony, v nich instruuji JavaScript a frontend běží nad
>>> > tím? Existuje to dlouho a Basecamp (37signals) to používá odjakživa,
>>> teď
>>> > tomu dali akorát webovku a název, protože je štval nedostatek
>>> protiváhy k
>>> > termínům jako SPA a Jamstack.
>>> >
>

Re: [django-cs] Django + Vue = VL? Nebo je to úplně jinak?

[Jan Walter]

My píšeme FE nejčastěji v Angularu (TypeScript), používáme Django REST
Framework, pomocí drf-yasg vygenerujeme openapi schéma a z něj naším
(opensource) generátorem vygenerujeme celou komunikační vrstvu na FE, čili
tímhle netrávíme ani minutu času, v běžných scénářích je vše krásné a
otypované (jeden model).


Určitě takovou věc lze najít/mít i pro react/vue.

On Tue, 23 Feb 2021, 09:41 Stanislav Vasko, 
wrote:

> Jasně, znám a používám. Běhá to skvěle a jak jsem psal: REST API je v
> Django sranda. Ale má-li mít API každý model, má-li API umět doposlat
> kontextové informace, pak nějaké přepínače, atd. začne se to nabalovat.
> Proto tam “remcám”, že sice to běhá a běhá to skvěle, ale všemu napsat API,
> vše ve Vue rozbalit a nandat do správný proměnný a pak teprve psát šablonu
> je proti Django response/request časově úplně jinde a u menších aplikací se
> mi zdá, že budu více pracovat na API než aplikaci. Snad to píši
> srozumitelně :)
>
> SV
>
>
> On 23 February 2021 at 9:37:15, Jirka Vejrazka (jirka.vejra...@gmail.com)
> wrote:
>
> Ja v tomhle nejsem odbornik, ale REST API jsem kdysi davno v dobe bronzove
> delal pomoci https://www.django-rest-framework.org/ - znas?
>
>   Jirka
>
> On Tue, 23 Feb 2021 at 09:30, Stanislav Vasko 
> wrote:
>
>> Díky za přehledné shrnutí. Pere se to ve mě, varianta B je asi ideál, a
>> díky tomu, že Vue uvažuji jen jako FE aplikací, nevýhody se SEO mi nevadí.
>>
>> Co mi žene krev do očí je to API. Ano, REST API v Django je sranda,
>> zvláště pak v tutoriálech. Ale reálně… svět je jinde. V contextu či def
>> serve() si udělám s daty cokoliv, hlavně pak snadno pořídím kontextové
>> informace a ještě v šabloně se dá případně leccos, když je člověk pohodlný.
>> Ale co s Vue, pro všechno psát API? Nebo vše neustále balit do JSON a na
>> druhé straně rozbalovat? Na velkých projektech s oddělením na BE a FE
>> pohoda a dokonce i výhoda, ale u malých projektů zcela mimo, protože s
>> programováním komunikace Django <-> Vue bych strávil více času než s
>> aplikací samotnou.
>>
>> Uvidím na té mé aplikaci, buď jsem něco významného přehlédl a lze si
>> celou integraci zjednodušit nebo prostě budu muset zůstat u Django + AJAX a
>> Vue řešit až po přechodu na zcela jiný BE.
>>
>> SV
>>
>>
>> On 23 February 2021 at 8:31:43, Martin Kubát (mar.ku...@gmail.com) wrote:
>>
>> Zdravím,
>> ano, volba b) je v poslední době běžná. Je tam mnoho a mnoho problémů,
>> ale také to má své výhody:
>>
>>- čistě FE (vue, angular, react,. ...) je špatně čitelný pro roboty
>>(některé), je třeba řešit server-side-rendering (firebase, ...)
>>- ano, je třeba objevovat kolo hlavně z pohledu routování url adres
>>- většinou je třeba dva lidi/týmy - BE/FE.
>>- nutnost udržování dokumentace API
>>- FE frameworky mají životnost jepice - od začátku psaní tohoto mailu
>>do konce bylo určitě vydáno několik main verzí reactu, angularu, npm a
>>javascriptu...
>>
>>
>>
>>- znovupoužitelnost BE api je super v tom, že se může připojit jak
>>web frontend, tak např. mobilní aplikace, nebo prostě nějaký konzument 3.
>>strany.
>>- člověk se na BE nemusí starat o html/css a řeší jen databázi,
>>performance, rest/graphql ... (vyhovuje teda alespoň mě)
>>- na tvorbu microservis je to velmi výhodný koncept.
>>- ve větším týmu je krásně řešitelné rozdělení rolí (na fullstack
>>nevěřím)
>>- front je zpravidla rychlejší, tahá se méně dat. UI/UX je možné
>>dotáhnout k dokonalosti. Na druhou stranu to žere mnoho více paměti v
>>prohlížeči.
>>
>>
>> Asi bych mohl pokračovat, ale myslím, že základní body jsem napsal.
>>
>> MK
>>
>> po 22. 2. 2021 v 21:55 odesílatel Stanislav Vasko <
>> stanislav.va...@gmail.com> napsal:
>>
>>> Zdravím,
>>>
>>> stále více mi chybí JS ve frontendu. Prošel jsem si co dneska frčí a
>>> poměrně jasně jsem si našel Vue jako náplast na moji bolístku. Líbí se mi
>>> ta reaktivita a naproti ReactJS má víc té “magie” out-of-the-box. Prostě,
>>> nějak k němu inklinuji, tak snad to není špatná volba.
>>>
>>> Takže, pustil jsem se víc do studia, prošel tutoriály, pročetl nějakou
>>> tu knihu a koukl výuková videa. V podstatě jsem našel 2 možnosti integrace:
>>> 1. vložit odkaz na Vue.js pro sem-tam využití JS funkce nebo 2. mít ve Vue
>>> celý frontend, který je na Django zcela nezávislý. Ta druhá cesta je asi
>>> správná, ale trochu mi vadí/děsí, že se vlastně učím celý další framework a
>>> naopak všechno “to krásné” z Django je významně zredukováno na něco málo
>>> víc než prosté ORM a REST API. Navíc deploy znamená neustále řešit
>>> vystavení 2 nezávislých aplikací, které spolu úzce souvisí.
>>>
>>> Chci se jen ujistit, že ORM s REST API + Vue je běžná cesta a opravdu se
>>> to takto používá. Totiž druhá volba mi připadá nepříjemná ve dvou věcech:
>>> a) znovuobjevuji kolo, jen místo v Django budu věci dělat ve Vue a
>>> b) namísto psaní Django aplikace využiji ORM a pak donekonečna na vše
>>> vytvářím REST API konektory a ve Vue je 

Re: [django-cs] ponechani X poslednich objektu per group

[Jan Walter]

Ta 1) mi prijde fajn. Jen, pokud se nemylim, mladsi zaznamy maji vetsi ts,
cili nerovnosti > a >= (mazu ty, kde mladsich v grp je alespon 5). Alias je
a, ne x, snad. Plus to predpoklada unikatnost ts.

On Sat, 20 Feb 2021, 17:57 Honza Král,  wrote:

> Ahoj,
>
> pristupy ktere znam (muze jich byt vic a/nebo existovat lepsi:
>
> 1) subselect ktery vrati poradi podle ktereho pak muzes filtrovat:
>
> DELETEFROM
>   my_table xWHERE (
>   SELECT
> COUNT(*)
>   FROM
> my_table
>   WHERE
> grp = a.grp
>   AND
> ts <= a.ts
> ) <= 5
>
>
> 2) pouziti window functions (
> https://www.postgresql.org/docs/9.1/tutorial-window.html) uprimne nevim,
> jak delete, ale u SELECT vypada takhle nejak:
>
>SELECT * FROM (
> SELECT *,
> rank() OVER (
> PARTITION BY grp
> ORDER BY ts DESC
> )
> FROM my_table
> ) rank_filter
> WHERE RANK > 5
>
>
> 3) me oblibene - nedelej to a delej to pri vkladani zaznamu ktere vzdy
> budes nasledovat jednoduchym DELETE ktere vymaze jen ty zaznamy pro grp
> kterou zrovna upravujes.
>
> Snad neco z toho pomuze.
>
>
> On Sat, Feb 20, 2021 at 4:59 PM Vladimír Macek  wrote:
>
>> Ahoj,
>>
>> mějme model s fieldy timestamp (ts) a skupina (grp).
>>
>> Máte někdo odladěný příkaz (ORM nebo při nejhorším SQL), který smaže
>> všechny objekty, které jsou pro danou grp starší než 5 nejmladších dle ts?
>>
>> V Pythonu to samozřejmě umím, ale mohl by to dokázat postgres. :-)
>>
>> Díky,
>>
>> V.
>>
>>
>> --
>> --
>> E-mailová skupina django-cs@googlegroups.com
>> Správa: http://groups.google.cz/group/django-cs
>> ---
>> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
>> django-cs ve Skupinách Google.
>> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny,
>> zašlete e-mail na adresu django-cs+unsubscr...@googlegroups.com.
>> Chcete-li zobrazit tuto diskusi na webu, navštivte
>> https://groups.google.com/d/msgid/django-cs/b297f00f-9a6b-8e29-7b3a-2b9305d722a4%40sandbox.cz
>> .
>>
> --
> --
> E-mailová skupina django-cs@googlegroups.com
> Správa: http://groups.google.cz/group/django-cs
> ---
> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
> „django-cs“ ve Skupinách Google.
> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny,
> zašlete e-mail na adresu django-cs+unsubscr...@googlegroups.com.
> Chcete-li tuto diskusi zobrazit na webu, navštivte
> https://groups.google.com/d/msgid/django-cs/CADoCwr0m2RDqzw%3DnM70uMb4u%2BqCgSUNKFN%3D5ebAfYNLF9QRUoA%40mail.gmail.com
> 
> .
>

-- 
-- 
E-mailová skupina django-cs@googlegroups.com
Správa: http://groups.google.cz/group/django-cs
--- 
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny django-cs 
ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete 
e-mail na adresu django-cs+unsubscr...@googlegroups.com.
Chcete-li zobrazit tuto diskusi na webu, navštivte 
https://groups.google.com/d/msgid/django-cs/CAK-vJU%3DQ4TzycoiiKYjOYN1fCUhANYA%3DWTtoaodeWokD4OZ-Hw%40mail.gmail.com.

Re: [django-cs] Jak zjistit jméno projektu

[Jan Walter]

Asi nejsem sto se přesně naladit na charakter Tvého problému, ale pokud
mohu poradit obecně, snažil bych se vystříhat tomu, aby "bylo na produkci
pokaždé něco jinak".

My v partě máme oblíbený docker, což je technologie využitelná např. na to,
aby bylo, pokud možno, "všude všechno v základu stejně". Doporučuji Tvé
pozornosti.

John

On Fri, 19 Feb 2021, 19:32 MirekZv,  wrote:

> Běží mi kód ve stacku projektu,
> ale dotyčný soubor se nachází mimo adresář projektu.
> Jak bych zjistil jméno projektu?
>
> Abych to trochu vysvětlil:
> V běžných django settings se řeší přesně toto, co potřebuju, třeba nějak
> přibližně takto:
> BASE_DIR = Path(__file__).resolve().parent.parent
> PROJECT_NAME = BASE_DIR.name
>
> Potřebuju totéž zjistit v souboru, který není v BASE_DIR.
> A to tak, že nechci nic nastavovat nikde v souborech pod BASE_DIR.
>
> Napadají mě 2 možnosti:
> - zjistit to nějak z inspect.stack() --ale nevím, jak to udělat dost
> bezpečně
> - vzít jenom os.getcwd() --za předpokladu, že mám úplně standardní
> projekt, se stejným jménem rootu i adresáře projektu
>
> Zatím jsem se spokojil s tím posledním.
> Myslíte, že by na to mohl být spoleh ve všech variantách na produkci?
>
> Alternativně: Dá se nějak snadno zjistit z kódu settings file (protože ten
> mám pod projektem; nebo prostě jakýkoli file, který je bezpečně pod
> adresářem projektu (např. ve stacku mám jako první manage.py, jenže to asi
> na produkci bude pokaždé jinak).
>
> Díky, tedy kdyby někdo věděl.
>
> --
> --
> E-mailová skupina django-cs@googlegroups.com
> Správa: http://groups.google.cz/group/django-cs
> ---
> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
> „django-cs“ ve Skupinách Google.
> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny,
> zašlete e-mail na adresu django-cs+unsubscr...@googlegroups.com.
> Chcete-li tuto diskusi zobrazit na webu, navštivte
> https://groups.google.com/d/msgid/django-cs/2c569772-cc17-437d-80ec-0411a0207c33n%40googlegroups.com
> 
> .
>

-- 
-- 
E-mailová skupina django-cs@googlegroups.com
Správa: http://groups.google.cz/group/django-cs
--- 
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny django-cs 
ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete 
e-mail na adresu django-cs+unsubscr...@googlegroups.com.
Chcete-li zobrazit tuto diskusi na webu, navštivte 
https://groups.google.com/d/msgid/django-cs/CAK-vJU%3D6zQW99QbNdrXSC7jGxNVxEB7y39M%2BDYUi%3DJQMG_MwLA%40mail.gmail.com.

Re: [django-cs] Jedna aplikace nasazená pro více projektů různých firem - jak na modifikace?

[Jan Walter]

Z vlastních zkušeností bych doporučil:
- Mít vše v 1 repositáři - tzv. monorepo. Balíčky, knihovny, verzování,
kompatibilita, je to hrozně administrativy navíc, základem monorepa jsou
dobrý testy i na ty klientsky specifický funkčnosti.
- Neodlišovat klientské verze větvemi, je to akorát další příležitost se v
tom utopit. Udržoval bych jednotnou hlavní vývojovou linii (dev, stage,
prod, nebo jak je libo/potřeba) a tam aktuální zdrojáky všeho a pro všechny.

Klíčem bude vždy dobře předem zvážit, která funkcionalita je specifická a
která obecná. Ale monorepo přecejen dává větší flexibilitu věci přesouvat.
Společné funkce bych držel za každou cenu stejné (zejm. na úrovni modelů).
I specifické funkce lze často zavádět na základě obecných mechanismů
(jednotné rozhraní).

Další otázkou je, jak se verze budou provozovat - 1 instance pro všechny
(zde jsi již udělal rozhodnutí s různými db, ale úvaha o společné db je
určitě validní), nebo na druhé straně spektra on-site u/pro konkrétního
klienta. Potřeby se můžou v čase významně měnit. Ale i tady poskytuje
monorepo větší flexibilitu z hlediska experimentů a změn dle potřeb.

Hodně štěstí,
John

On Sat, 12 Sep 2020, 09:39 Jakub Vysoky,  wrote:

> Abychom ti dokazali spravne poradit, museli bychom vedet, jak velike jsou
> rozdily v tech jednotlivych "instalacich" pro ruzne klienty.
>
> Za me je urcite "spravne" mit:
>
> * jednu spolecnou knihovnu v niz je vetsina funkcionality (vetsina django
> apps)
> * virtualenv per klient
> * v kazdem virtualenvu pro kazdeho klienta jejich vlastni django projekt
> (cili django settings, INSTALLED_APPS)
> * nejspis i v tom vlastnim projektu jednu django appku, kterou mohu
> customizovat sablony, pridavat nejakou funkcionalitu, ktera je unikatni pro
> daneho klienta
>
> Vsechno bych instaloval pomoci pipu - i kdyz to bude z nekolika vlastnich
> repositaru - to neni zas takovy problem. A urcite mel minimalne na upgrade
> nejaky skript, at to volam vzdycky stejne. Ansible je urcite super, ale
> muze byt pro tebe prekazka na nauceni se.
>
> Stejne tak mozna v tvem pripade by moje navrhovane oddeleni bylo zbytecne
> silne. Ale ja bych to videla do budoucna nejspolehlivejsi.
>
> Drzim palce!
>
>
> On Sat, Sep 12, 2020 at 2:11 AM Vladimír Macek  wrote:
>
>> Ahoj,
>>
>> a) jedna z cest na začátku vývoje byla, že bys měl projekt koncipovaný
>> jako multi-tenant, tzn. databáze a globální objekty (glob. objekty, cache,
>> fajly, ...) by s izolací klientů počítaly. Pak bys to měl na jednu stranu
>> jednoduché s údržbou. Bylo by ale neustále nutné hlídat tu izolaci a
>> udržovat rozdíly ve funkčnostech.
>>
>> b1) Když by funkčních rozdílů mezi doménami bylo míň, můžeš vyvíjet JEDEN
>> projekt pro všechny, provozovat pro každého klienta extra instanci, ale z
>> JEDNOHO branche. Funkční rozdíly mezi doménami by se rešily výhybkami v
>> kódu.
>>
>> Zdrojáky na serveru můžou být jen jednou, dokonce i virtualenv jen jeden,
>> jen různé settings, databáze a file storage.
>>
>> b2) Větší funkční oddělený celek, by se dal uzavřít do apky, kterou by v
>> INSTALLED_APPS měli jen příslušní klienti. Pozor, stále se z ní dá
>> importovat.
>>
>> c) Silnější varianta je udržovat takovou per-instance apku jako separátně
>> instalovanou jen do virtualenvu příslušného klienta. Pak by importovatelná
>> nebyla, ale pro klienty bys již musel udržovat oddělené virtualenvy.
>>
>> Zde bych jit doporučil nástroj na automatický deployment, například
>> Ansible. Nedávno jsem ho zavedl do svého toolsetu a je opravdu fajn.
>> Deployneš novou verzi všem najednou, klidně s customizacemi.
>>
>> d) Může tě zaujmout ještě další varianta: Společnou část projektu bys
>> udržoval v hlavním git branchi, třeba 'prod' (jako produkční). A pak bys
>> pro klienta požadujícího změnu vytvořil branch 'prod-klient1', ve které by
>> oproti 'prod' byly změny, které tento klient chtěl.
>>
>> Vývoj a bugfixy společných částí bys pushoval do 'prod' a hned mergnul do
>> všech 'prod-*' branchů. Abys nezapomněl, můžeš si nastavit různé git hooky
>> -- jen varovací nebo i blokující, že třeba nepushneš 'prod-*', pokud jsi do
>> něj zapomněl mergnout 'prod'.
>>
>> Chce to jenom větší sebekázeň, ale git je na souběžný vývoj přímo dělaný.
>> Výhody jsou, že git ti vždycky krásně zobrazí diffy mezi společnou verzí a
>> klienty i mezi klienty navzájem. U žádného klienta není kód navíc.
>> Nespolečné commity si navždy ponesou své messages, kde svému budoucímu já
>> podrobně vysvětlíš, proč existují. To se u výhybek ne vždy daří. Viděl bych
>> i omezený dosah chyb v 'prod-*' brenčích. Další výhoda mě napada, že když
>> při mergi do 'prod-*' dojde někde k průniku změn (nechci říkat přímo
>> kolizi), přiměje tě to k úvaze, jestli dělení funkčností koncipuješ dobře.
>>
>> Ansible ti opět na jediný příkaz deployne do virtualenvů všech klientů,
>> každého z příslušného branche gitu.
>>
>> V každém případě si veď dokumentaci kdy, kdo, chtěl jakou změnu, proč ji
>> chtěl, jak jsi s ním o úpravě diskutoval. Tvým 

Re: [django-cs] python-daemon

[Jan Walter]

Myslíš aby byly kontejnery na různých hostech v jedné síti? To ne. Nejsem
síťař, nemám tušení, jak by se to dělalo. Má na to docker nějaké
prostředky? Nebo vpn?

Úložiště si umím představit líp, ale teď si nevybavuju, že bychom to někde
dělali.

On Sat, 19 Oct 2019, 12:44 Petr Messner,  wrote:

>
> > 19. 10. 2019 v 12:11, Jan Walter :
> >
> > celej ekosystem kontejneru vs. sdilenych siti, ulozist,
>
> Řešíte sdílené sítě/úložiště i nějak napříč fyzickými servery (docker
> hosty)?
>
> Petr Messner
>
> --
> --
> E-mailová skupina django-cs@googlegroups.com
> Správa: http://groups.google.cz/group/django-cs
> ---
> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
> django-cs ve Skupinách Google.
> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny,
> zašlete e-mail na adresu django-cs+unsubscr...@googlegroups.com.
> Chcete-li zobrazit tuto diskusi na webu, navštivte
> https://groups.google.com/d/msgid/django-cs/ECEC6CD0-7E43-4F4D-A8C3-E69996A4CF02%40gmail.com
> .
>

-- 
-- 
E-mailová skupina django-cs@googlegroups.com
Správa: http://groups.google.cz/group/django-cs
--- 
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny django-cs 
ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete 
e-mail na adresu django-cs+unsubscr...@googlegroups.com.
Chcete-li zobrazit tuto diskusi na webu, navštivte 
https://groups.google.com/d/msgid/django-cs/CAK-vJUko64OvUk%2Bh-RiPteD0%3D4PAqCRN1HJXENyRnzh1A7Xkqg%40mail.gmail.com.

Re: [django-cs] python-daemon

[Jan Walter]

Jasne, to Tvoje spusteni s parametrem je, myslim, efektivne totez, jako to
mit napsany v yml pro docker compose jak to mame my. Mne se na nem naopak
libi, ze mas prehledne na 1 miste nadefinovanej celej ekosystem kontejneru
vs. sdilenych siti, ulozist, muzes mit i fragmenty definovany ve vice
souborech a ty pak skladat/pretezovat pro ruzna prostredi.

Uplne bez chyb ten design neni, ale nasli jsme si zpusob, zije nam to s
ansiblem (asi to teda spoustime trochu rucne, nikoli dedikovanym modulem),
mozna mi neco uniklo, ale vlastne nevim, kde je zasadni rozdil mezi sadou
docker runs s vhodnyma parametrama a docker compose.

On Sat, 19 Oct 2019, 11:45 Petr Messner,  wrote:

> Ten restart umí udělat samotný docker - stačí kontejner spustit přes
> docker run --restart always :) (Mozna stačí -r?) Viz dokumentaci:
> https://docs.docker.com/engine/reference/run/#restart-policies---restart
>
> Docker compose se mi nelíbí, dělá to spoustu blbostí navíc. Docker lze
> ovládat z cfgmgmt systémů typu Ansible, Salt apod., ale tam se mi taky
> nějaké detaily nelíbily :) Takže mám vlastní skript v Pythonu, který celkem
> jednoduchým způsobem managuje kontejnery na daném stroji podle yaml
> předpisu (takže stejná myšlenka jako compose, jen par detailů jinak).
> Docker má pro Python přímo oficiální modul, ale neni problém skriptovat i
> okolo docker cli příkazu (přepnout si jeho výstup do json a tak).
>
> Petr Messner
>
> 19. 10. 2019 v 11:23, Jan Walter :
>
> 
> Ad docker: jakou používáte techniku pro nahození kontejnerů po (re)startu
> docker služby, resp. pádu kontejneru? My jsme si oblíbili docker compose
> s restart: unless-stopped.
>
> Dík za případnou inspiraci.
>
> On Sat, 19 Oct 2019, 10:32 Petr Messner,  wrote:
>
>> Dneska mají všechny rozumné distribuce systemd. Jediné, co potřebuješ, je
>> napsat Python program, který něco dělá, a ideálně umí korektně reagovat na
>> SIGTERM. Ani fork nebo double fork už nemusíš dělat, to za tebe řeší
>> systemd. A pak ještě vytvoříš systemd unit file a pak už jen systemctl
>> start :)
>>
>> Pokud bys šel do Dockeru, tak je postup stejný - jen místo systemd unit
>> file napíšeš Dockerfile.
>>
>> Petr Messner
>>
>> > 19. 10. 2019 v 7:34, Jachym Cepicky :
>> >
>> > Ahoj všem,
>> >
>> > potřeboval bych napsat v Pythonu démona - proces běžící na pozadí,
>> > který po zbytek svého životního cyklu tiše sedí v systému a dělá co
>> > má.
>> >
>> > Možnosti jsou od prostého
>> >
>> > mujdaemon.py &
>> >
>> > až po sofistikovanější python-daemon
>> >
>> > python-daemon má ten problém, že dokumentace k tomu moc není, postrádá
>> > to metody stop, restart, ... nebo aspoň návod jak si je udělat a vůbec
>> > si nejsem jistej, že pidfile funguje tak, jak bych čekal (např. že mě
>> > nenechá pustit dva daemony najednou)
>> >
>> > máte s tím někdo zkušenosti? nějakej funkční příklad?
>> >
>> > Dík
>> >
>> > J
>> >
>> > --
>> > Jachym Cepicky
>> > e-mail: jachym.cepicky gmail com
>> > URL: http://les-ejk.cz
>> > GPG: http://les-ejk.cz/pgp/JachymCepicky.pgp
>> >
>> > --
>> > --
>> > E-mailová skupina django-cs@googlegroups.com
>> > Správa: http://groups.google.cz/group/django-cs
>> > ---
>> > Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
>> django-cs ve Skupinách Google.
>> > Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny,
>> zašlete e-mail na adresu django-cs+unsubscr...@googlegroups.com.
>> > Chcete-li zobrazit tuto diskusi na webu, navštivte
>> https://groups.google.com/d/msgid/django-cs/CAAZUH4GDjxoO_ezPW%2B%3DJuAemzu3wTCMJ64iDNjGvRWYLaGMA%2Bg%40mail.gmail.com
>> .
>>
>> --
>> --
>> E-mailová skupina django-cs@googlegroups.com
>> Správa: http://groups.google.cz/group/django-cs
>> ---
>> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
>> django-cs ve Skupinách Google.
>> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny,
>> zašlete e-mail na adresu django-cs+unsubscr...@googlegroups.com.
>> Chcete-li zobrazit tuto diskusi na webu, navštivte
>> https://groups.google.com/d/msgid/django-cs/B2D76930-A1DE-4132-BD1D-A3CB58C38CE3%40gmail.com
>> .
>>
> --
> --
> E-mailová skupina django-cs@googlegroups.com
> Správa: http://groups.google.cz/group/django-cs
> ---
> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
> „django-cs“ ve Skupinách Google.
> Chcete-li zrušit odběr skupiny

Re: [django-cs] python-daemon

[Jan Walter]

Ad docker: jakou používáte techniku pro nahození kontejnerů po (re)startu
docker služby, resp. pádu kontejneru? My jsme si oblíbili docker compose
s restart: unless-stopped.

Dík za případnou inspiraci.

On Sat, 19 Oct 2019, 10:32 Petr Messner,  wrote:

> Dneska mají všechny rozumné distribuce systemd. Jediné, co potřebuješ, je
> napsat Python program, který něco dělá, a ideálně umí korektně reagovat na
> SIGTERM. Ani fork nebo double fork už nemusíš dělat, to za tebe řeší
> systemd. A pak ještě vytvoříš systemd unit file a pak už jen systemctl
> start :)
>
> Pokud bys šel do Dockeru, tak je postup stejný - jen místo systemd unit
> file napíšeš Dockerfile.
>
> Petr Messner
>
> > 19. 10. 2019 v 7:34, Jachym Cepicky :
> >
> > Ahoj všem,
> >
> > potřeboval bych napsat v Pythonu démona - proces běžící na pozadí,
> > který po zbytek svého životního cyklu tiše sedí v systému a dělá co
> > má.
> >
> > Možnosti jsou od prostého
> >
> > mujdaemon.py &
> >
> > až po sofistikovanější python-daemon
> >
> > python-daemon má ten problém, že dokumentace k tomu moc není, postrádá
> > to metody stop, restart, ... nebo aspoň návod jak si je udělat a vůbec
> > si nejsem jistej, že pidfile funguje tak, jak bych čekal (např. že mě
> > nenechá pustit dva daemony najednou)
> >
> > máte s tím někdo zkušenosti? nějakej funkční příklad?
> >
> > Dík
> >
> > J
> >
> > --
> > Jachym Cepicky
> > e-mail: jachym.cepicky gmail com
> > URL: http://les-ejk.cz
> > GPG: http://les-ejk.cz/pgp/JachymCepicky.pgp
> >
> > --
> > --
> > E-mailová skupina django-cs@googlegroups.com
> > Správa: http://groups.google.cz/group/django-cs
> > ---
> > Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
> django-cs ve Skupinách Google.
> > Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny,
> zašlete e-mail na adresu django-cs+unsubscr...@googlegroups.com.
> > Chcete-li zobrazit tuto diskusi na webu, navštivte
> https://groups.google.com/d/msgid/django-cs/CAAZUH4GDjxoO_ezPW%2B%3DJuAemzu3wTCMJ64iDNjGvRWYLaGMA%2Bg%40mail.gmail.com
> .
>
> --
> --
> E-mailová skupina django-cs@googlegroups.com
> Správa: http://groups.google.cz/group/django-cs
> ---
> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
> django-cs ve Skupinách Google.
> Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny,
> zašlete e-mail na adresu django-cs+unsubscr...@googlegroups.com.
> Chcete-li zobrazit tuto diskusi na webu, navštivte
> https://groups.google.com/d/msgid/django-cs/B2D76930-A1DE-4132-BD1D-A3CB58C38CE3%40gmail.com
> .
>

-- 
-- 
E-mailová skupina django-cs@googlegroups.com
Správa: http://groups.google.cz/group/django-cs
--- 
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny django-cs 
ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete 
e-mail na adresu django-cs+unsubscr...@googlegroups.com.
Chcete-li zobrazit tuto diskusi na webu, navštivte 
https://groups.google.com/d/msgid/django-cs/CAK-vJUmO9SOPOnahd5ZhKt12LPxCifuuZ1CtR7bWc3F3VArk_Q%40mail.gmail.com.

Re: [django-cs] Re: Python

[Jan Walter]

Kolik je Ti let? Doporučuju začít studiem Pythagorovy věty.

On Sun, 16 Dec 2018, 21:06 Maskot Lindo,  wrote:

> Skúsil sem všechno a neumim nic
>
> --
> --
> E-mailová skupina django-cs@googlegroups.com
> Správa: http://groups.google.cz/group/django-cs
> ---
> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
> django-cs ve Skupinách Google.
> Chcete-li zrušit odběr skupiny a přestat dostávat e-maily ze skupiny,
> zašlete e-mail na adresu django-cs+unsubscr...@googlegroups.com.
> Chcete-li zobrazit tuto diskusi na webu, navštivte
> https://groups.google.com/d/msgid/django-cs/a57cd74d-d496-451b-ba36-c2911539e261%40googlegroups.com
> .
> Další možnosti najdete na adrese https://groups.google.com/d/optout.
>

-- 
-- 
E-mailová skupina django-cs@googlegroups.com
Správa: http://groups.google.cz/group/django-cs
--- 
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny django-cs 
ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e-maily ze skupiny, zašlete 
e-mail na adresu django-cs+unsubscr...@googlegroups.com.
Chcete-li zobrazit tuto diskusi na webu, navštivte 
https://groups.google.com/d/msgid/django-cs/CAK-vJUk3Lb%2BkwT8sr62wwOL0MQE-f-3gjVYZs1NzcQSm592TwA%40mail.gmail.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

Re: [django-cs] Volba databáze a její možnosti

[Jan Walter]

Nevim jak dneska, ale mysql nebyla pred lety dobra (plnohodnotna) relacni
db, postgres je naopak supr uz hodne dlouho. Svyho casu jsem si napr. delal
benchmarky rychlosti beznych r/w operaci pro vetsi stromovy struktury
(postgres, mssql, neo4j) a postgres vychazel v podstate nejlip.

Plus indexace json typu pro flexibilitu, jak rika starenka, podle me
robustni (jedno z mnoha, urcite) reseni.

Bezny dotaz na par tisic zaznamu z par milionu musi byt za destitky max
malo stovek ms, jak rikaji ostatni.

Jinymi slovy postgres rozhodne neni spatna volba.

On Fri, 30 Nov 2018, 12:12 Jirka Vejrazka,  wrote:

> Tri miliony radku jsou jen drobne, pokud spravne pouzijes indexy. Mel bys
> byt na zlomcich sekund pro jeden dotaz (a pokud ten dotaz nevraci tisice
> zaznamu)...
>
>  Jirka
>
>
>
> On Fri, 30 Nov 2018 at 10:34, Stanislav Vasko 
> wrote:
>
>> V mezičase jsem si napsal miniaplikaci, která natahala nějaká data z
>> Heureky a pak jsem skriptem začal soubor dat duplikovat. Aktuálně mám v
>> SQLite asi 3 milióny řádků vše běží, jen tedy vyhledat data s jedinou WHERE
>> podmínkou a sortem je cca 10s (45000 výsledků), s limitem na 10 pak cca
>> 6,5s. Zkusil jsem MySQL a tam jsou reakce lepší, ale hlavně pokud zapisuji
>> do DB mohu z ní v pohodě číst. Což asi bude to hlavní důvod, proč SQLite
>> nebude možné použít, neboť budu potřebovat umět současně zapisovat i číst.
>> Robot pořízující nová data může běžet taky 15-30 minut a nemohu po tuto
>> dobu aplikaci odstavit či házet errory.
>>
>> Nevíte o nějakém prakticky pojatém článku o tom jak si v MySQL či PSQL
>> ušetřit čas a nervy využitím nějakých robotů/automatiky pro zpracování dat
>> do mezitabulek, virtuálních dat apod.? Myslím, že využití a vytahání dat z
>> miliónů řádek pro dashboard apod. by měl robot v DB umět určitě lépe než
>> cokoliv co spáchám já :)
>>
>> Díky!
>>
>> On Thursday, 29 November 2018 22:17:08 UTC+1, Vítek Pliska wrote:
>>>
>>> Určitě scrapy může i v tomto případě pomoct např. s tím jak pracuje s
>>> concurrent requests a třebas autothrottle - to záleží na pravidlech toho
>>> API které se bude konzumovat, co je dovoleno/jaké jsou limity. Pokud není
>>> dovoleno dělat víc požadavků najednou tak bych tam asi scrapy ani netahal…
>>>
>>> Vítek
>>>
>>> 29. 11. 2018 v 22:09, Honza Javorek :
>>>
>>> Já bych řekl, že se specializuje na těžení a že má dost věci, které ti
>>> to těžení usnadní, pokud jde o HTML. Pokud jde o JSON, nic usnadňovat
>>> nepotrebujes, mas json.loads(), a pak ale pořad stavis na tom těžení.
>>>
>>> HJ
>>>
>>> On Thu, 29 Nov 2018 at 21:05, Petr Messner  wrote:
>>>
 Ahoj,

 myslel jsem, že scrapy se specializuje na těžení dat z HTML. Říkáš, že
 se hodí i na JSON API?

 Petr

 čt 29. 11. 2018 v 20:47 odesílatel Honza Javorek 
 napsal:

> Ahoj,
>
> mirne offtopic, ale pokud muzu komentovat tu cast kde budes
> bombardovat to API, tak bych zvazil https://scrapy.org/ On si clovek
> casto nemysli ze neco takovyho potrebuje, az kdyz do toho zabredne a trva
> to misto tri dnu mesic, tak si uvedomi, ze misto requests mohl pouzit
> nejaky framework.
>
> Honza
>
> On Thu, Nov 29, 2018 at 8:19 PM Stanislav Vasko 
> wrote:
>
>> Díky za info. Jen zopakuji, že počet dotazů je pro Heureku skoro nic,
>> proti jiným partnerům. Současné scrapování mám nejen povolené, ale hlavně
>> tuto novou aplikaci budu napojovat (základní skripty jsou už hotové) přes
>> API, které Heureka nedávno uvolnila, zpoplatnila přístup a je na toto 
>> přímo
>> postaveno.
>>
>> JSON soubory mně také napadly, vlastně bych mohl ukládat přímo
>> odpovědi z API (je to JSON RPC), ale nevím jak praktické to je pro další
>> zpracování. Musel bych pravidelně robotem tahat aktuální data denně
>> vypočítat pak dlouhodobé statistiky, ale něco takového mně u DB řešení 
>> čeká
>> asi také. Ještě mně napadlo, zda by nebylo efektivnější pro tyto účely
>> využít nějaký skripty přímo v DB, tuším, že některé mají přímo "udělátka"
>> na vypočítání dat, virtuálních tabulek apod. To by mi možná ušetřilo 
>> práci
>> a vyřešilo nutnost neustále o data nějak pečovat.
>>
>> Kibana vypadá zajímavě, ale přiznám se, že o ní slyším poprvé a vůbec
>> nevím jak to v tomto pojetí uchopit. Zkusím si něco nastudovat, ale 
>> raději
>> bych se držel něčeho co zná každý a kdokoliv případně i poradí.
>>
>> Díky!
>>
>> On Thursday, 29 November 2018 20:05:21 UTC+1, Messa wrote:
>>>
>>> Ahoj,
>>>
>>> tohle scrapování určitě vidí Heureka strašně ráda. Ale to je tvůj
>>> boj :)
>>>
>>> 60 tisíc záznamů denně? Hm, na to by stačil i JSON soubor. Paradoxně
>>> by jeho zpracování mohlo být i rychlejší, než ze špatně navržené 
>>> databáze.
>>>
>>> Což ostatně není špatný nápad, si ta data vylít a zpracovávat mimo.
>>> Je to celkem častý postup (oddělení analytické db 

Re: [django-cs] Django ORM

[Jan Walter]

Nebudu opakovat již vyřčené, jen Ti můžu říct z pohledu člověka, který
kdysi s SQL strávil hodně času a měl ho moc rád, že Django má ORM api moc
hezký, zvykneš si rychle, a ujetej sql jazyk už nebudeš chtít pro běžný
situace používat. Je to mnohem čitelnější, rychlejší na použití.

Zkus a uvidíš.

Btw, dobře nastavený indexy, integritní omezení, konfiguraci db atp.
potřebuješ v obou případech.

On Tue, 14 Aug 2018, 11:59 Martin Kubát,  wrote:

> Zdravím,
>
>1. django ORM je první volba. Django je tímto úzce spjato. Bude určitě
>existovat nějaká knihovna, která umí django+SQLAlchemy, ale moc bych na to
>nevsázel. To už je pak lepší flask + SQLAlchemy.
>2. nevím o tom, ORM si toto řídí dle druhu vazby
>3. viz 4.
>4. asi zalezi na db enginu, ale na postgresu SELECT ... WHERE id =
>max(id) udělat nelze. Musis group by id a pak having, a to je rozhodne
>delsi, nez order by id. Na id je standardne index.
>5. asi jo, ale nedokazu poradit
>6. nektere veci proste nejdou, resi se to
>
> https://docs.djangoproject.com/pl/2.1/topics/db/sql/#performing-raw-sql-queries,
>nebo nizkourovnove primo sql.
>7. určitě. django ORM je jednoduché, i kdyz v posledních letech toho
>umí více a více. Na SQLAlchemy ale jestě úplně nemá. Namátkou nativní
>polymorfismus.
>
> Debugovat dotazy z ORM je urcite dobre a po nejake praxi se i v ramci ORM
> budou psat dotazy rychleji a spravne.
>
> Hodně zdaru.
> MK
>
>
>
> út 14. 8. 2018 v 10:59 odesílatel PavelZet  napsal:
>
>> Ahoj, chci se zeptat, zda
>>
>> 1) opravdu všichni pro výběr dat z databáze používáte Django ORM ?
>> 2) jak lze určit zda použít INNER nebo OUTER JOIN ?
>> 3) když chci vyhledat entitu s posledním ID, tak nejlepší volbou je forma
>> SELECT ... WHERE id = max(id)
>> jak ji dosáhnu?
>> zkoušel sem .filter(id=Max(id)), který ale použije pomalejší HAVING místo
>> optimálního WHERE
>> SELECT ... HAVING id = max(id)
>> 4) proč všichni používají zápis .latest() (resp.
>> .order_by(id)[:1].get()), který srovná celou tabulku a vybere poslední
>> prvek formou
>> SELECT ... ORDER BY id DESC LIMIT 1
>> což je pomalejší a obecně o něco horší možnost ?
>> 5) existuje nějaký dobrý tutoriál z pohledu SQL, kde jasně uvidím jak
>> psát ORM formu, abych dosáhl konkrétního SQL ?
>> 6) napíšu v ORM obecně jakkoli zamotaný SQL dotaz? nebo sou věci které
>> prostě nejdou?
>> 7) jsou případy na které se Django ORM vyloženě nehodí a musí se použít
>> náhradní řešení ?
>>
>> Jsem zvyklý si optimalizované SQL dotazy psát sám. Samotný dotaz mám
>> napsaný rychle.
>> Nevýhoda byla, že musím myslet na escapování vstupů a poté musím mapovat
>> výsledné pole na entitu. Toho bych se rád z časových důvodů zbavil.
>> Na to se hodí ORM.
>>
>> V ORM řešení mám vše napsané rychle a funkčně, to je fajn a jeví se dobře.
>> ALE poté musím dotazy ještě debugovat, googlit a editovat tak, aby vznikl
>> optimální SQL dotaz, jaký si představuju. Takže časová úspora je zase tatam
>> :(
>>
>> Díky za reakce znalých.
>>
>> --
>> --
>> E-mailová skupina django-cs@googlegroups.com
>> Správa: http://groups.google.cz/group/django-cs
>> ---
>> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
>> „django-cs“ ve Skupinách Google.
>> Chcete-li zrušit odběr skupiny a přestat dostávat e-maily ze skupiny,
>> zašlete e-mail na adresu django-cs+unsubscr...@googlegroups.com.
>> Chcete-li tuto diskusi zobrazit na webu, navštivte
>> https://groups.google.com/d/msgid/django-cs/879de872-c7c6-4aad-b00f-d9a9a58f6ae9%40googlegroups.com
>> 
>> .
>> Další možnosti najdete na https://groups.google.com/d/optout.
>>
> --
> --
> E-mailová skupina django-cs@googlegroups.com
> Správa: http://groups.google.cz/group/django-cs
> ---
> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
> „django-cs“ ve Skupinách Google.
> Chcete-li zrušit odběr skupiny a přestat dostávat e-maily ze skupiny,
> zašlete e-mail na adresu django-cs+unsubscr...@googlegroups.com.
> Chcete-li tuto diskusi zobrazit na webu, navštivte
> https://groups.google.com/d/msgid/django-cs/CA%2BL8erbnznv5YrMu4i5O4pis5O79LAEKQQ-shhEVYT9Vahgt4w%40mail.gmail.com
> 
> .
> Další možnosti najdete na https://groups.google.com/d/optout.
>

-- 
-- 
E-mailová skupina django-cs@googlegroups.com
Správa: http://groups.google.cz/group/django-cs
--- 
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny django-cs 
ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e-maily ze skupiny, zašlete 
e-mail na adresu django-cs+unsubscr...@googlegroups.com.
Chcete-li zobrazit tuto diskusi na webu, navštivte 

Re: [django-cs] WSGI vs. dev server

[Jan Walter]

Petre, dik moc za podrobnej vhled. Trochu lip chapu souvislosti.
Nicmene, jak pise Starenka, presnej duvod odlisnyho chovani (jo, myslel
jsem mod_wsgi vs. manage.py ve virtualenvu) jsem zatim nenazrel. V jednom
ze svych experimentu jsem z envu smazal tu knihovnu, co jsem volal, a zaclo
to padat, ze chybi - cili se urcite pouzivala v obou modelech. Odlisnost
musela bejt nekde hloubejc.
Vlastne me nejvic fascinuje, ze nikde (viditelne) nebyla zadna chybova
hlaska, proste ta metoda suverenne vracela prazdnej retezec.

Nicmene je to jasny memento, ze je to model hodny opusteni, prejdu na
gunicorn (uwsgi?), kde cejtim vetsi jistotu, ze ty volani lezou stejnou
cestou.

Dik moc,
John

On Fri, Jun 23, 2017 at 9:12 AM starenka . <staren...@gmail.com> wrote:

> Me by teda taky zajimalo, v cem byl zakopanej pes. Pokud neco potrebovalo
> libxml2, je to vetsinou lxml nebo neco podobnyho (libxml2-dev a libxslt-dev
> baliky na debosich). Nechapu, jak to bez tech baliku mohlo fungovat.
> Protoze v tom virtualenvu to prece musela lehnout pri instalaci ty
> knihovny, ktera tohle potrebuje, cili by si vedel, ze je neco spatne. Pokud
> bys to mel blbe nakonfeny a env by to bralo ze systemu, tak by si taky na
> to zahy prisel, protoze na 99% nemas urcite v globalnich site packages
> nainstalovany veci, ktery appka potrebuje.
>
> Ad gunicorn: jo, je to standard. Pak je tady par lidi (ehm ehm), ktery
> proste jednou zkusili uwsgi a ne gunicorn a nemeli duvod menit ;)
>
> Letos sme na pyconu meli o uwsgi talk, kdyby te to zajimalo
> https://m.youtube.com/watch?v=2Azpwf2LRK0=279m0s
> -
> 'aknerats'[::-1]
>
> On Jun 23, 2017 03:22, "Petr Messner" <petr.mess...@gmail.com> wrote:
>
>> Dne 20. června 2017 2:25 Jan Walter <jnw...@gmail.com> napsal(a):
>>
>>> Protože se mi nepovedlo rychle rozběhnout gunicorn (nedával jsem teď pár
>>> let pozor, to je standard i pro produkci?), debuggoval jsem nainstalovaný
>>> balíček, našel podezřelou závislost libxml2, nainstaloval její systémový
>>> balík a následně udělal nový env a pip install, kde se leccos souvisejícího
>>> buildovalo. Moje chápání podstaty a zejm. odlišnosti mezi manage.py a wsgi
>>> je dost na vodě, ale třeba to přes noc docvakne. Kdybyste mi to někdo uměl
>>> jednoduše vysvětlit, budu nadšen stejně, jako že to už funguje :).
>>>
>>>
>> Tak gratuluji :)
>>
>> "odlišnosti mezi manage.py a wsgi" - tím "wsgi" asi myslíš mod_wsgi.
>> Protože mod_wsgi a WSGI jsou různé věci :)
>>
>> Co dělá manage runserver: spustí django.core.servers.basehttp.WSGIServer ,
>> který je odvozený od wsgiref import simple_server ze standardní knihovny
>> Pythonu, a jako handler to tomu dá Django WSGI handler, který umí odpovídat
>> na requesty. Toto vše běží v kontextu toho příkazu manage.py, takže pod
>> venvem, pod kterým to spouštíte.
>>
>> Co dělá gunicorn: gunicorn je web server naimplementovaný v Pythonu,
>> můžete si ho nainstalovat do venvu. Django aplikace se v něm spouští opět
>> přes WSGI handler té Django aplikace. Situace je v podstatě stejná jako při
>> "manage runserver", akorát místo wsgiref.simple_server se použije gunicorn
>> webserver. Ta Django aplikace běží přímo v procesech nebo vláknech
>> spuštěných gunicornem, pokud gunicorn spustíte z venvu, tak i Django
>> aplikace bude používat tenhle venv.
>>
>> Co dělá mod_wsgi: je to modul do Apache webserveru. Apache je napsaný v C
>> a i moduly do něj jsou v C. Python se z něj spouští pomocí Python C API
>> (Python.h):
>> https://github.com/GrahamDumpleton/mod_wsgi/blob/033bfc7ac5bce9bacb9bbc7594f48d7c5551df3a/src/server/wsgi_interp.c#L2263
>> Takže např. to, jaká verze Pythonu se spustí, záleží na tom, oproti čemu
>> byl mod_wsgi zkompilovaný a s čím je nalinkovaný (libpython). Teoreticky se
>> může stát, že by mohly kolidovat závislosti (C knihovny) Python modulů a
>> Apache (nebo ostatních *_mod v Apache).
>>
>> A jak do toho všeho zapadá venv? venv je jen sada adresářů, která
>> obsahuje Python moduly. Pokud spustíte python "normálně", tj. bez venvu,
>> tak se pro importované moduly použije cesta např.
>> /usr/lib/python3/dist-packages. Když spustíte python ve venvu (např.
>> venv/bin/python), tak se pustí ten Python (binárka), pomocí kterého byl
>> tento venv vytvořen, jen se místo cesty /usr/lib/python3/dist-packages
>> použije venv/lib/python3.5/site-packages.
>>
>> Jak je to s venv a mod_wsgi? Tady může nastat rozpor v tom, pomocí které
>> Python binárky byl ten venv vytvořen, a pomocí čeho (libpython) potom ten
>> kód spouští mod_wsgi - jestli tyhle dvě věci (python binárka a l

Re: [django-cs] WSGI vs. dev server

[Jan Walter]

Protože se mi nepovedlo rychle rozběhnout gunicorn (nedával jsem teď pár
let pozor, to je standard i pro produkci?), debuggoval jsem nainstalovaný
balíček, našel podezřelou závislost libxml2, nainstaloval její systémový
balík a následně udělal nový env a pip install, kde se leccos souvisejícího
buildovalo. Moje chápání podstaty a zejm. odlišnosti mezi manage.py a wsgi
je dost na vodě, ale třeba to přes noc docvakne. Kdybyste mi to někdo uměl
jednoduše vysvětlit, budu nadšen stejně, jako že to už funguje :).

Každopádně dík moc za pomoc,
John

On Mon, Jun 19, 2017 at 12:20 PM Petr Messner <petr.mess...@gmail.com>
wrote:

> Přinejhorším můžeš kód toho balíku upravit (editovat přímo soubor v envu)
> a dát si tam nějaké debug logování.
>
> A když si to spustíš přes gunicorn místo mod_wsgi, tak to funguje? Kdoví,
> oproti jakému python interpretreu je ten mod_wsgi zkompilovaný.
>
> PM
>
> Dne 19. června 2017 11:02 Jan Walter <jnw...@gmail.com> napsal(a):
>
>> Díky moc za nápady.
>>
>> Metodu volám s jednoduchým modelovým vstupem totožným v obou případech.
>> Vypsal jsem si v místě volání locals() a globals() (ne do hloubky).
>> Jediný, co vidím jako odlišnost je cesta k importovaným balíčkům
>> /home/ct/www/env/local/lib/python2.7/site-packages/django/db/models/__init__.pyc
>> (apache) vs.
>> /home/ct/www/env/lib/python2.7/site-packages/django/db/models/__init__.pyc
>> (manage.py)
>> nicméně local je jen link
>> lrwxrwxrwx 1 ct ct 20 Jun 18 20:52 /home/ct/www/env/local/lib ->
>> /home/ct/www/env/lib
>>
>> Apache běží pod jiným uživatelem (WSGIDaemonProcess má ale nastaven
>> atribut user), je to asi dobrá hypotéza; i když jsem ale dal celýmu obsahu
>> virtualenvu rwx, je to beze změny. Možná nějaký pracovní soubory, adresáře,
>> rychle jsem prohlídl, jestli to něco čte (bez úspěchu), ještě to budu muset
>> prozkoumat víc. Divný je, že to nepíše žádnou chybu, suverénně to vrátí ''.
>> Je to v principu věc, která z jednoho řetězce udělá jiný bez dalších
>> externalit.
>>
>> Dost možná přehlížím něco úplně triviálního, až to najdu, dám vědět.
>>
>> Ještě jednou díky.
>>
>>
>> On Mon, Jun 19, 2017 at 8:57 AM Vláďa Macek <ma...@sandbox.cz> wrote:
>>
>>> Ahoj,
>>>
>>> to jsou nepříjemný problémy. Mimochodem, jakmile to půjde, opravdu
>>> upgraduj
>>> Django.
>>>
>>> Neznám premailer, ale vypadá to, že nemá nic společného s běhovým
>>> prostředím/middlewary, takže by nemělo na způsobu spuštění záležet.
>>>
>>> Odhaduju, že bude mít jiné vstupy. V obou případech si "vytiskni" vše, co
>>> leze do konstruktoru třídy Premailer a do té metody a porovnej, budou tam
>>> rozdíly.
>>>
>>> Nezapomeň na objekty v globálních identifikátorech, které mohou taky
>>> změnit
>>> chování. Django settings je taky globální. Filesystém je globální.
>>> Ovlivněn
>>> může být i kód volaný z modulu premailer.py (nebo jím děděný, nebo i z
>>> něj
>>> děděný) a tedy to hned nevidíš.
>>>
>>> Vytiskni si i výstupy těsně před oběma returny. Je možné, že jsi se
>>> přehlédl a problém bude někde jinde. Mozek je mrška a někdy sám sebe
>>> přesvědčí o nesmyslu.
>>> (
>>> http://s2.quickmeme.com/img/fe/fe6a68c7673a3ae9b8856a27ab2ddbe578daedd9755be7cda3182ed8252d3743.jpg
>>> )
>>>
>>> V.
>>>
>>>
>>> On 19.6.2017 07:52, Jan Walter wrote:
>>> > Ahoj,
>>> > mám problém, se kterým si nevím moc rady. Spočívá v odlišnosti výsledku
>>> > volání jedné specifické metody přes Apache mod_wsgi vs. vývojový server
>>> > via manage.py runserver (nebo i interaktivní shell) v konzoli.
>>> >
>>> >  1. Django 1.5.4 (vím, není to soudobé).
>>> >  2. Volám metodu transform z premailer knihovny
>>> > (
>>> https://github.com/peterbe/premailer/blob/master/premailer/premailer.py#L279
>>> ).
>>> >  3. Když to zavolám pomocí manage.py (runserver nebo shell), funguje
>>> > naprosto OK - distribuuje styly do elementů vstupního dokumentu.
>>> >  4. Když ji volám přes Apache, vrací prázdný řetězec, žádná chyba.
>>> Stejný
>>> > vstup, stejný virtual env.
>>> >
>>> > Máte nějakou ideu, co na to může mít vliv, co by mohlo být jinak, resp.
>>> > co/jak debuggovat? Jsem už trochu bez nápadů.
>>> >
>>> > Dík moc za případnou inspiraci,
>>> > John
>>>
>>> --
>>> --
>>> E-mailová skupina 

Re: [django-cs] WSGI vs. dev server

[Jan Walter]

Díky moc za nápady.

Metodu volám s jednoduchým modelovým vstupem totožným v obou případech.
Vypsal jsem si v místě volání locals() a globals() (ne do hloubky). Jediný,
co vidím jako odlišnost je cesta k importovaným balíčkům
/home/ct/www/env/local/lib/python2.7/site-packages/django/db/models/__init__.pyc
(apache) vs.
/home/ct/www/env/lib/python2.7/site-packages/django/db/models/__init__.pyc
(manage.py)
nicméně local je jen link
lrwxrwxrwx 1 ct ct 20 Jun 18 20:52 /home/ct/www/env/local/lib ->
/home/ct/www/env/lib

Apache běží pod jiným uživatelem (WSGIDaemonProcess má ale nastaven atribut
user), je to asi dobrá hypotéza; i když jsem ale dal celýmu obsahu
virtualenvu rwx, je to beze změny. Možná nějaký pracovní soubory, adresáře,
rychle jsem prohlídl, jestli to něco čte (bez úspěchu), ještě to budu muset
prozkoumat víc. Divný je, že to nepíše žádnou chybu, suverénně to vrátí ''.
Je to v principu věc, která z jednoho řetězce udělá jiný bez dalších
externalit.

Dost možná přehlížím něco úplně triviálního, až to najdu, dám vědět.

Ještě jednou díky.


On Mon, Jun 19, 2017 at 8:57 AM Vláďa Macek <ma...@sandbox.cz> wrote:

> Ahoj,
>
> to jsou nepříjemný problémy. Mimochodem, jakmile to půjde, opravdu upgraduj
> Django.
>
> Neznám premailer, ale vypadá to, že nemá nic společného s běhovým
> prostředím/middlewary, takže by nemělo na způsobu spuštění záležet.
>
> Odhaduju, že bude mít jiné vstupy. V obou případech si "vytiskni" vše, co
> leze do konstruktoru třídy Premailer a do té metody a porovnej, budou tam
> rozdíly.
>
> Nezapomeň na objekty v globálních identifikátorech, které mohou taky změnit
> chování. Django settings je taky globální. Filesystém je globální. Ovlivněn
> může být i kód volaný z modulu premailer.py (nebo jím děděný, nebo i z něj
> děděný) a tedy to hned nevidíš.
>
> Vytiskni si i výstupy těsně před oběma returny. Je možné, že jsi se
> přehlédl a problém bude někde jinde. Mozek je mrška a někdy sám sebe
> přesvědčí o nesmyslu.
> (
> http://s2.quickmeme.com/img/fe/fe6a68c7673a3ae9b8856a27ab2ddbe578daedd9755be7cda3182ed8252d3743.jpg
> )
>
> V.
>
>
> On 19.6.2017 07:52, Jan Walter wrote:
> > Ahoj,
> > mám problém, se kterým si nevím moc rady. Spočívá v odlišnosti výsledku
> > volání jedné specifické metody přes Apache mod_wsgi vs. vývojový server
> > via manage.py runserver (nebo i interaktivní shell) v konzoli.
> >
> >  1. Django 1.5.4 (vím, není to soudobé).
> >  2. Volám metodu transform z premailer knihovny
> > (
> https://github.com/peterbe/premailer/blob/master/premailer/premailer.py#L279
> ).
> >  3. Když to zavolám pomocí manage.py (runserver nebo shell), funguje
> > naprosto OK - distribuuje styly do elementů vstupního dokumentu.
> >  4. Když ji volám přes Apache, vrací prázdný řetězec, žádná chyba. Stejný
> > vstup, stejný virtual env.
> >
> > Máte nějakou ideu, co na to může mít vliv, co by mohlo být jinak, resp.
> > co/jak debuggovat? Jsem už trochu bez nápadů.
> >
> > Dík moc za případnou inspiraci,
> > John
>
> --
> --
> E-mailová skupina django-cs@googlegroups.com
> Správa: http://groups.google.cz/group/django-cs
> ---
> Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny
> django-cs ve Skupinách Google.
> Chcete-li zrušit odběr skupiny a přestat dostávat e-maily ze skupiny,
> zašlete e-mail na adresu django-cs+unsubscr...@googlegroups.com.
> Chcete-li zobrazit tuto diskusi na webu, navštivte
> https://groups.google.com/d/msgid/django-cs/1e0c244c-708e-3ca0-2c86-df0732efd594%40sandbox.cz
> .
> Další možnosti najdete na adrese https://groups.google.com/d/optout.
>

-- 
-- 
E-mailová skupina django-cs@googlegroups.com
Správa: http://groups.google.cz/group/django-cs
--- 
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny django-cs 
ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e-maily ze skupiny, zašlete 
e-mail na adresu django-cs+unsubscr...@googlegroups.com.
Chcete-li zobrazit tuto diskusi na webu, navštivte 
https://groups.google.com/d/msgid/django-cs/CAK-vJU%3DRi0b4--HQX1%3DXxvAKjMDQS9BZDcHjFFxgCqn-t0W9YQ%40mail.gmail.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

[django-cs] WSGI vs. dev server

[Jan Walter]

Ahoj,
mám problém, se kterým si nevím moc rady. Spočívá v odlišnosti výsledku
volání jedné specifické metody přes Apache mod_wsgi vs. vývojový server via
manage.py runserver (nebo i interaktivní shell) v konzoli.

   1. Django 1.5.4 (vím, není to soudobé).
   2. Volám metodu transform z premailer knihovny (
   https://github.com/peterbe/premailer/blob/master/premailer/premailer.py#L279
   ).
   3. Když to zavolám pomocí manage.py (runserver nebo shell), funguje
   naprosto OK - distribuuje styly do elementů vstupního dokumentu.
   4. Když ji volám přes Apache, vrací prázdný řetězec, žádná chyba. Stejný
   vstup, stejný virtual env.

Máte nějakou ideu, co na to může mít vliv, co by mohlo být jinak, resp.
co/jak debuggovat? Jsem už trochu bez nápadů.

Dík moc za případnou inspiraci,
John

-- 
-- 
E-mailová skupina django-cs@googlegroups.com
Správa: http://groups.google.cz/group/django-cs
--- 
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny django-cs 
ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e-maily ze skupiny, zašlete 
e-mail na adresu django-cs+unsubscr...@googlegroups.com.
Chcete-li zobrazit tuto diskusi na webu, navštivte 
https://groups.google.com/d/msgid/django-cs/CAK-vJUknM%3D4PDrJFD%3Dt-xbe38nL%2B8P-W1xmCYJpN17WqKR-1Vg%40mail.gmail.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

Re: [django-cs] Nova aplikace - jaka architektura

[Jan Walter]

Připojím poznámku k FE (django OT).

On 18.10.2014 11:29, Radek Svarz wrote:
JS framework: angularJS / backbone.js / ember ? (btw, mam radeji 
deklarativni zapis, nez algoritmicky)


backbone.js jsme používali a přešli na angularjs. Netvrdím, že jsme to 
měli v bb navržený geniálně, ale ačkoli jsme aplikaci překlápěli několik 
měsíců, brzo se nám vrátily.
Je to daleko rychlejší na prototypy (řešíš model + šablonu, o zbytek se 
±nestaráš) a snadnější na zapojení nových/jr programátorů v průběhu 
(rychleji se zorientují).
Pokud bys ovšem měl tendenci zobrazovat v prohlížeči víc dat, dožene Tě 
nutnost (tupý zobrazení velkýho množství dat s přehledem zabije 
prohlížeč) optimalizovat (selektivně zjednodušovat $digest cyklus, 
ubírat $watch-e, upouštět od ryze deklarativního stylu), takže si to 
může znatelnou část ušetřeného času vzít zpátky.
I tak jsem optimista a v principu doporučuju, autoři angularu jsou borci 
a mají solidní podporu v Googlu i komunitě.


John

P. S. Hezký počtení pro dlouhé zimní večery např. zde 
http://tutorials.jenkov.com/angularjs/critique.html.


--
--
E-mailová skupina django-cs@googlegroups.com
Správa: http://groups.google.cz/group/django-cs

--- 
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny django-cs ve Skupinách Google.

Chcete-li zrušit odběr skupiny a přestat dostávat e-maily ze skupiny, zašlete 
e-mail na adresu django-cs+unsubscr...@googlegroups.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

[django-cs] OAuth/OpenID autentizace

[Jan Walter]

Ahoj,
doporučíte něco na autentizaci 3. stranami via OAuth/OpenID (primárně 
fb, google, linkedin)? Po zběžném čtení jsem vytipoval django-allauth a 
python-social-auth. Potřebuju to rychle zadrátovat do stávající 
aplikace, kde používáme django.contrib.auth, aby to bylo ovšem 
flexibilní do budoucna.


Dík za názor,
John

--
--
E-mailová skupina django-cs@googlegroups.com
Správa: http://groups.google.cz/group/django-cs

--- 
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny django-cs ve Skupinách Google.

Chcete-li zrušit odběr skupiny a přestat dostávat e-maily ze skupiny, zašlete 
e-mail na adresu django-cs+unsubscr...@googlegroups.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

Re: [django-cs] Stylování formulářů

[Jan Walter]

Díky moc Vám všem za inspiraci.
Po osahání jsem zvolil cestu vlastních mikrošablon, které se hodí pro 
náš projekt.


Floppy vypadá sympaticky, ale protože dědíme od formulářů 
django.contrib.auth.forms (a ne přímo z django.forms), nebyl by přechod 
úplně hladký.


John

--
--
E-mailová skupina django-cs@googlegroups.com
Správa: http://groups.google.cz/group/django-cs

--- 
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny django-cs ve Skupinách Google.

Chcete-li zrušit odběr skupiny a přestat dostávat e-maily ze skupiny, zašlete 
e-mail na adresu django-cs+unsubscr...@googlegroups.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

[django-cs] Stylování formulářů

[Jan Walter]

Drazí odborníci na Django,

byl bych moc rád, pokud byste mě inspirovali vhodným směrem v 
následující oblasti. Pro registraci (a další operace s ní související) 
uživatele používáme formuláře děděné od tříd z 
django.contrib.auth.forms. Potřebuji jim v html definovat nějaké další 
atributy (typicky class, placeholder, možná další) a hledám elegantní 
způsob, jak to udělat.


Doufám, že z pochopitelných důvodů, to chci dělat v šablonách (css bych 
rád držel v html, nikoli v py zdrojáku). Jediný způsob, který vidím, je 
zapomenout na {{form.username}} a rovnou vložit  podle potřeby. 
Což mi také nepřijde ideální, protože ztrácím vazbu na model. I kdybych 
přistoupil na definici v py, nevidím elegantní způdob, jak některé 
společné vlastnosti polí formuláře definovat na jednom místě. Můžu v 
každé třídě udělat něco jako


username = forms.CharField(
label=_("Username"),
max_length=75,
widget=forms.TextInput(attrs={
'class': 'inp-text',
'placeholder': _('Password')
})
)

nebo

def __init__(self, *args, **kwargs):
super(MyAuthenticationForm, self).__init__(*args, **kwargs)
for field in self.fields.itervalues():
widget = field.widget
if isinstance(widget, forms.TextInput):
widget.attrs['class'] = 'inp-text'
widget.attrs['placeholder'] = field.label

ale to se mi nelíbí, budu mít hodně redundantního kódu.
Napadlo mě vytvoření Mixin třídy nebo dekorátoru, který by uměl polím 
různých tříd vnutit atributy jednotně, ale nedotáhl jsem to, nejsem 
přesvědčen o schůdnosti takového řešení.



Možná řeším něco, co je v rozporu s filosofií Djanga (chci modifikovat 
něco, co má fungovat standardně), hledám teď nejlepší způsob, jak 
nasadit hotové ostylované šablony dodané zvenku.



Díky za jakýkoli hint,

John

--
--
E-mailová skupina django-cs@googlegroups.com
Správa: http://groups.google.cz/group/django-cs

--- 
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny django-cs ve Skupinách Google.

Chcete-li zrušit odběr skupiny a přestat dostávat e-maily ze skupiny, zašlete 
e-mail na adresu django-cs+unsubscr...@googlegroups.com.
Další možnosti najdete na adrese https://groups.google.com/d/optout.

[django-cs] Hledáme Django experta pro Common Tongue

[Jan Walter]

Vážení přátelé,

v těchto dnech jsme začali shánět posilu pro rozvoj našeho ambiciozního 
produktu pro obecný time management.
Primárně hledáme chytrého a pracovitého člověka se zájmem o téma, který má 
bohaté zkušenosti s Python/Django.
Dobrá znalost JavaScriptu a ještě lépe zkušenost přímo s AngularJS jsou 
vítané.

V případě zájmu o intenzivní a dlouhodobou spolupráci dejte vědět.


Díky,

Jan Walter
john at commontongue dot com
+420777319931

http://www.commontongue.com/
http://www.startupjobs.cz/nabidka/970/python-and-or-angularjs-developer

-- 
-- 
E-mailová skupina django-cs@googlegroups.com
Správa: http://groups.google.cz/group/django-cs

--- 
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny django-cs 
ve Skupinách Google.
Pokud chcete zrušit odběr skupiny, aby vám z ní již nechodily e-maily, zašlete 
e-mail na adresu django-cs+unsubscr...@googlegroups.com.
Další možnosti najdete na adrese https://groups.google.com/groups/opt_out.