abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 02:22 | Pozvánky

Fedora 31 Release Party, tj. oslava nedávného vydání Fedory 31, se uskuteční ve středu 20. listopadu v Brně. Program přednášek bude upřesněn.

Ladislav Hagara | Komentářů: 0
dnes 01:11 | Nová verze

Příspěvek na blogu webové aplikace pro spolupráci na zdrojových kódech pomocí gitu Gitea (Wikipedie) představuje novinky a ukazuje náhledy nové major verze 1.10.0 této v programovacím jazyce Go naprogramované aplikace. Nově jsou například vedle sebe zobrazovány původní a nové verze obrázků.

Ladislav Hagara | Komentářů: 0
včera 22:33 | IT novinky

Společnost Docker stojící za stejnojmennou kontejnerovou technologií čelila vážným finančním problémům. Stávající investoři do ní ale vložili dalších 35 milionů dolarů a společnost Mirantis odkoupila Docker Enterprise.

Ladislav Hagara | Komentářů: 0
včera 16:11 | IT novinky

Od 24. listopadu bude možné předobjednat přenosný počítač Pocket Popcorn Computer (Pocket P.C.) s 1.2 GHz Quad-Core ARM Cortex-A53 CPU, 2GB DDR3 RAM, 32GB eMMC Memory, 4.95" Full HD IPS LCD a 3200 mAh Removable Battery. Počítač by měl být odesílán v květnu 2020. Předinstalován by měl být Debian 10.

Ladislav Hagara | Komentářů: 23
včera 11:11 | Komunita

Canonical věnoval nadaci UBports další telefony a tablety pro podporu vývoje Ubuntu Touch, tj. Ubuntu pro telefony a tablety. Vybraní vývojáři Ubuntu Touch je mohou získat zdarma.

Ladislav Hagara | Komentářů: 7
včera 09:33 | Zajímavý projekt

Společnost GitHub v rámci svého GitHub Archive Programu vytvoří několik off-line záloh open source softwaru nacházejícího se na GitHubu pro budoucí generace. První taková záloha všech aktivních repozitářů proběhne 2. února 2020 ve spolupráci se společností Pigl na jejich piqlFilmy a uložena bude v Arktickém světovém archivu. Případné obnovení ze zálohy by mělo být možné i za 1 000 let.

Ladislav Hagara | Komentářů: 6
včera 05:55 | Nová verze

Dnes a zítra probíhá v Praze konference Internet a Technologie 19 pořádaná sdružením CZ.NIC. Sledovat ji lze online.

Ladislav Hagara | Komentářů: 1
13.11. 19:44 | Nová verze

Brendan Eich, mj. autor JavaScriptu a několikadenní CEO Mozilly, představil v lednu 2016 webový prohlížeč Brave (Wikipedie, GitHub). Dnes byla vydána verze 1.0 tohoto webového prohlížeče. K dispozici jsou také balíčky pro Linux.

Ladislav Hagara | Komentářů: 11
13.11. 17:11 | Pozvánky

Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 170. brněnský sraz, který proběhne v pátek 15. listopadu od 18:00 v restauraci Vegalité (Slovákova 10).

Ladislav Hagara | Komentářů: 2
13.11. 11:55 | Nová verze

Po půl roce vývoje od vydání verze 5.2 byla vydána nová verze 5.3 svobodného open source redakčního systému WordPress. Kódové označení Kirk bylo vybráno na počest amerického jazzového multiinstrumentalisty Rahsaana Rolanda Kirka.

Ladislav Hagara | Komentářů: 9
Jaké hodinky nosíte (nejčastěji)?
 (24%)
 (7%)
 (14%)
 (55%)
Celkem 147 hlasů
 Komentářů: 10, poslední včera 16:20
Rozcestník
Štítky: není přiřazen žádný štítek

www.AutoDoc.Cz


Vložit další komentář
5.11. 21:12 Miriam
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí

Vlákno bylo přesunuto do samostatné diskuse.

6.11. 00:03 .
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí
neprodukuje xD
5.11. 21:34 _
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí
Hezke. Nemyslim si ale ze se jedna o budoucnost. Tak jako budoucnost neni lisp ackoli se jedna o bezkonkurencni jazyk. V komunite lisperu koluji o padu lispu ruzne historky.

Jedna z nich je

„Worse is Better“
Bystroushaak avatar 5.11. 21:57 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí
Přijde mi docela zajímavé vidět, že některé z těch myšlenek se už uchycují v masivně používaných IDE. Například existují pluginy do Eclipse a PyCharm/Idea si z toho taky bere inspiraci, i když zatím stále velmi nedokonale. Autor v knize odkazuje spousty studií a odkazy na různé další implementace a jde docela vidět, že za těch pár let od vydání knihy se tenhle trend jen zesiluje.
5.11. 22:28 _
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí
Nektere myslenky se urcite dostanou do mainstreamu, rozhodne ale ne tak jak byli originalne zamysleny. Jsem v tomto skeptik. Uz pred 20 lety bylo vse pripraveno na revoluci ve vnimani abstrakce, jedine co chybelo byli lide kteri by toho byli schopni.
Bystroushaak avatar 5.11. 22:43 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí
Nemyslím si že chyběli lidé, ale spíš se to stalo v prostředích, které neměly dostatečně silný síťový efekt. Smalltalky jsou toho klasickým příkladem, v té době často vyžadující speciální hardware, nebo mající brutálně vysoké ceny za licence (jakože třeba 5 tisíc dolarů per user). Lisp, specificky pak lisp machines a Genera jsou další takové prostředí - drahé, málo rozšířené a nerozvinutelné komunitou kolem toho, kvůli licencím a proprietárnosti.

Další důvod, proč to dneska začínáme vidět všude možně kolem je růst abstrakce obecně v jazycích a prostředích kolem nich. I nízkoúrovňové jazyky jako Java postupně inovují a různá IDE a prostředí už moc nemají co vymýšlet, tak se začínají vytahovat na světlo staré koncepty, které dlouho nikdo neoprášil. Samozřejmě to pořád nemá na dvacet let starý Smalltalk, ale podle mě to pohání bádání (spíš tápání) tímhle směrem.
5.11. 23:36 Pavel Křivánek | skóre: 28 | blog: Kvičet nezávaznou konverzaci
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí
Myslím, že úloha ceny se při výčtu důvodů, proč se Smalltalk nerozšířil, asi přeceňuje. Určitě hrála roli, ale třeba Smalltalk/V stál v roce 1986 99 USD (dnes asi 232 USD), což byla v té době cena na úrovni konkurečních vývojových prostředí. Myslím, že Smalltalk především doplatil na to, že silně předběhl svoji dobu. Měl vysoké HW nároky a nikdo ještě pořádně nevěděl, jak s takovým systémem správně pracovat. Jednotkové testování, refactoring a agilní vývoj byli rozvinuty až později (právě ve Smalltalku), takže si stačil získat pověst jazyka, ve kterém je příliš snadné vytvářet nepořádek. A v polovině devadesátých let se už dal těžko propagovat jako horká novinka a The Next Big Thing.
I'm sure it crashed in the most type-safe way possible.
5.11. 21:38  
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí
Prosím kategorii `teoretické masturbace co zůstanou vlchkým snem` za 2000.
5.11. 22:13 Pavel Křivánek | skóre: 28 | blog: Kvičet nezávaznou konverzaci
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí
Feenk na tomto snu dost intenzivně pracuje... https://youtu.be/Pot9GnHFOVU
I'm sure it crashed in the most type-safe way possible.
5.11. 22:42 -ğ-
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí
A přitom taková blbost, co?
6.11. 02:21 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí
Obecné developerské nástroje nenabízejí možnost přímo přemýšlet v termínech doménové abstrakce. To umožňují různé na míru dělané nástroje přímo pro konkrétní doménu.
S tim bych nesouhlasil. Nastroje to bez problemu zvladnou, hlavni potiz je v tom, ze programatori nejsou schopni vytvaret spravne a oddelene abstrakce.
Pro trénování systému vytvořil senior developer nástroj doménové abstrakce pro případ, kdy bylo nutné systém přetrénovat, protože něco vyhodnotil špatně.
Moudry to clovek ktery vedel, ze lze mit i nekolik urovni abstrakce nad sebou.

A ted, co tim chci rict.

Vytvorit abstrakci pro konkretni domenu nevyzaduje nejake specialni jazykove konstrukce (makra, transformace AST), ale bohate staci bezne prostredky jazyka (procedury, funkce, objekty) a k tomu pak jen nadhled nad problemem a disciplina.

Typicky nesvar i "zkusenych" programatoru je v tom, ze nevytvari jasne oddelene urovne abstrakce a bezne dochazi k prosakovani nizkourovnovych konstrukci do vysokourovnovych. Pujcim si priklad z prednasky, protoze se mi ted nechce vymyslet vlastni.
if (portfolioIdsByTraderId.get(trader.getId()).containsKey(portfolio.getId()) { ... }
Pricemz by to pri spravne navrzenych abstrakcich slo prepsat:
if (trader.canView(portfolio)) { ... }
Takto navrzeny kod je jednak snazsi pro porozumeni a zaroven to resi tvuj problem s debuggovanim. Vezmes si proceduru/metodu, kde je problem a jdes radek po radku (step-over, nemusis jit hloubeji, nechces-li), kdyz se dostanes nekam, kde uz je to moc low-level, vyskocis o level vys.

Programatori ale velice casto zabrednou do toho, ze vsechno je seznam/slovnik/tuple neceho (nektere jazyky k tomu vylozene svadi), coz pak vede k tomu, ze se michaji low-level reprezentace s kodem na vyssi urovni abstrakce a cteni a ladeni kodu zacina byt peklo.

Na druhou stranu psat kod, kde jsou vyrazne oddelene urovne abstrakce, je pro programatory nekomfortni hned z nekolika duvodu. Je to kod navic, proc si vytvaret vlastni tridu, kdyz mohu pouzit rovnou seznam/slovnik? Prinasi to urcitou rezii pri provadeni kodu. (Pro spoustu lidi mentalni blok.) Kdyz ma clovek dane hranice mezi abstrakcemi, kod neni tak tvarny, jak by mohl byt, coz nekteri povazuji za komplikaci (obvykle pri praseni).
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
6.11. 08:06 Pavel Křivánek | skóre: 28 | blog: Kvičet nezávaznou konverzaci
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí

Psát metody/funkce na jedné úrovni abstrakce je samozřejmě základ, ale samo o sobě to nezaručuje dobrou debugovatelnost. Můžete mít třeba cizí kód, který používá různé buildery, dekorátory a adaptory a získat přehled, co se v něm děje (pokud není velmi dobře zdokumentovaný) bude velmi obtížné. Viděl jsem takový případ, kdy si programátor prostě upravil debugger takovým způsobem, aby se mu během krokování zobrazoval průběžně se měnící graf objektů a referencí mezi nimi, který mu jej konečně pomohl pochopit.

Jinak většina současných debuggerů bývá navíc silně omezená. Málokterý umí třeba to si označit v příkladu výše kód trader.canView(portfolio) a spustit nad další instanci debuggeru s tím, že v té původní může kdykoliv pokračovat. Nebo, když už se člověk prostepuje do nějakého pro něj zajímavého stavu, tak by si jej mohl chít uložit, aby se do něj mohl vrátit až zjistí, že chyba, kterou hledá, vznikla na jiné úrovni abstrakce než předpokládal, a on ten bod při krokování překročil.

I'm sure it crashed in the most type-safe way possible.
Josef Kufner avatar 6.11. 11:12 Josef Kufner | skóre: 69
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí
Viděl jsem takový případ, kdy si programátor prostě upravil debugger takovým způsobem, aby se mu během krokování zobrazoval průběžně se měnící graf objektů a referencí mezi nimi, který mu jej konečně pomohl pochopit.
To by měla být celkem běžná věc. Potíž je, že to je obvykle docela obtížné udělat. Dobrá vizualizace dokáže několikanásobně zkrátit čas strávený laděním i vývojem. Kdyby debuggery umožňovaly snadno přidávat rozšíření na vykreslování různých datových struktur, tak by takový přístup byl docela běžný.

Já to teď řeším tak, že aplikace má ladicí a vizualizační nástroje integrované v sobě (v run-time i v testech), takže obrázky dostanu z ní namísto z debuggeru. Je to jednodušší na implementaci, ale má to celkem zjevné nedostatky.
Jinak většina současných debuggerů bývá navíc silně omezená. [...] a spustit nad další instanci debuggeru s tím, že v té původní může kdykoliv pokračovat.
To je dáno tím, že debugger se připojuje na běžící proces a ten není možné uložit a později restartovat. Ani není možné proces jen tak naklonovat. Volání fork() sice udělá kopii, ale nenaklonuje otevřené soubory a další externí věci.

Trochu praktičtější přístup jsou time-traveling debuggery, které si prostě ukládají průběžný stav aplikace a pak si můžeš krokovat obousměrně. Některé jazyky/frameworky takový debugger mají – je to o ukládání stavu aplikace mezi událostmi, který ten stav mění.
Hello world ! Segmentation fault (core dumped)
6.11. 12:12 Pavel Křivánek | skóre: 28 | blog: Kvičet nezávaznou konverzaci
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí
Já to teď řeším tak, že aplikace má ladicí a vizualizační nástroje integrované v sobě (v run-time i v testech), takže obrázky dostanu z ní namísto z debuggeru. Je to jednodušší na implementaci, ale má to celkem zjevné nedostatky.

Z tohoto důvodu některé jazyky nedělají rozdíly mezi vývojovým prostředím a vytvářenou aplikací, čímž takové bariéry eliminují.

To je dáno tím, že debugger se připojuje na běžící proces a ten není možné uložit a později restartovat. Ani není možné proces jen tak naklonovat. Volání fork() sice udělá kopii, ale nenaklonuje otevřené soubory a další externí věci.

Jenže ony to neumí ani debuggery v interpretovaných jazycích, které by s tím problém mít neměly...

I'm sure it crashed in the most type-safe way possible.
6.11. 12:54 snajpa | skóre: 20 | blog: snajpuv_blocek | Brno
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí
Kdyby debuggery umožňovaly snadno přidávat rozšíření na vykreslování různých datových struktur, tak by takový přístup byl docela běžný.
Mrkni na bpftrace a flame graphs.
Volání fork() sice udělá kopii, ale nenaklonuje otevřené soubory a další externí věci.
CRIU mozna?
--- vpsFree.cz --- Virtuální servery svobodně
Bystroushaak avatar 6.11. 13:43 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí
Já to teď řeším tak, že aplikace má ladicí a vizualizační nástroje integrované v sobě (v run-time i v testech), takže obrázky dostanu z ní namísto z debuggeru. Je to jednodušší na implementaci, ale má to celkem zjevné nedostatky.
Jo, tak jsem to nakonec vyřešil taky (dump do plantuml), to je právě ta tvorba doménových nástrojů.
Josef Kufner avatar 6.11. 13:53 Josef Kufner | skóre: 69
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí
Já nakonec vytvořil klon Graphvizu – Grafovátko, který funguje na webu (z JSON či JS kódu nakreslí SVG), neboť dělám webové věci, Graphviz na webu je obtížně použitelný a navíc si neporadil s některými grafy (a zdrojáky jsou strašné).
Hello world ! Segmentation fault (core dumped)
Bystroushaak avatar 6.11. 13:58 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí
Jo, to znám, i to plantuml má místy příšerný layout a vysvětlit tomu že něco chci občas nejde i s neviditelnými propojeními. Jak to vypadalo u mě je možné vidět tu.
Josef Kufner avatar 6.11. 14:24 Josef Kufner | skóre: 69
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí
Příloha:
To je ještě dobré. Tam aspoň ty čáry vedou kam mají. Viz příloha – je to jeden z těch méně zmršených.
Hello world ! Segmentation fault (core dumped)
6.11. 11:32 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí
Psát metody/funkce na jedné úrovni abstrakce je samozřejmě základ,
Ano je, ale obrovska cast programatoru toho neni schopna a kod je pak prolezly ruznymi ArrayList-y, HashMap-ami, tupli a vlastne si ani neuvedomuje, ze je na tom potencialne neco spatneho. Jazyky, ktere maji pohodlnou praci s temito datavymi typy, jsou na tom nejhur, protoze takove programovani z principu podporuji.
Můžete mít třeba cizí kód, který používá různé buildery, dekorátory a adaptory a získat přehled, co se v něm děje (pokud není velmi dobře zdokumentovaný)
To se domnivam, ze to je presne ten problem michani (prosakovani) urovni abstrakce.
Viděl jsem takový případ, kdy si programátor prostě upravil debugger takovým způsobem, aby se mu během krokování zobrazoval průběžně se měnící graf objektů a referencí mezi nimi, který mu jej konečně pomohl pochopit.
Toto "neni" problem ani treba v Eclipse (a patrne ani v zadnem jinem modernim IDE). To "neni" jsem dal do uvozovek, protoze toho kodu, jak se pripojit k existujicimu debuggeru a pracovat s nim, neni pro tento ucel zase tolik potreba, ale je hodne komplikovane zjistit, jak to udelat, protoze nikdo si s tim moc nelamal hlavu a dokumentace kulha. Ale to je spis nez koncepcni zalezitost zalezitost kvality. Verim, ze takove problemy budou v temer kazdem IDE bez ohledu na to, v cem je naprogramovane.
Nebo, když už se člověk prostepuje do nějakého pro něj zajímavého stavu, tak by si jej mohl chít uložit, aby se do něj mohl vrátit
To bohuzel zustane domenou jazyku (resp. runtimu), ktere umi ulozit kompletni stav a vratit se k nemu.

Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
6.11. 12:39 Pavel Křivánek | skóre: 28 | blog: Kvičet nezávaznou konverzaci
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí
Příloha:
To se domnivam, ze to je presne ten problem michani (prosakovani) urovni abstrakce.

Když pomineme to, že s takovým kódem se ve výsledku člověk bohužel setká nejčastěji, pak je ještě třeba říct, že i ve správně strukturovaném programu nemusí být krokování přímočaré. Jako třeba v klasickém případě rozesílání oznámení těm, kdo jsou pro jejich odběr přihlášení (viz obrázek). V jednom bodě se rozešle oznámení, které projde nějakým nízkoúrovňovým procesem, ve kterém se určuje, komu vlastně patří, a pak vybublá zpět na původní úroveň abstrakce někde úplně jinde. A odlišit to, které úrovně vlastně patří k sobě, musí buď pracně programátor sám. Nebo ten rozesílací framework umí rozšířit debugger takovým způsobem, že tyto informace poskytne programátorovi automaticky.

I'm sure it crashed in the most type-safe way possible.
6.11. 16:15 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí
Když pomineme to, že s takovým kódem se ve výsledku člověk bohužel setká nejčastěji, pak je ještě třeba říct, že i ve správně strukturovaném programu nemusí být krokování přímočaré.

Vzdyt to rikam, ze chyba neni v nastrojich, ale v tom, jak se pouzivaji.
odlišit to, které úrovně vlastně patří k sobě, musí buď pracně programátor sám. Nebo ten rozesílací framework umí rozšířit debugger takovým způsobem, že tyto informace poskytne programátorovi automaticky.
Ale jdete... pokud je kod naprogramovany alespon minimalne civilizovane, jsou jednotlive vrstvy rozdeleny do balicku. Neni pak problem v debuggeru oznacit, ktere low-level balicky se maji preskocit. Kdyz delam v Jave EE (tj. mam pod sebou brutalni moloch low-level veci), tak neco takoveho proste beru za uplnou samozrejmost a doted me nenapadlo, ze by s tim mohl byt problem nebo ze bych kvuli tomu musel hackovat debugger.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
Gréta avatar 6.11. 15:01 Gréta | skóre: 5 | blog: Grétin blogísek | Stockholm
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí
offtopic

dědo jak si sem dostal to zvýraznění syntaxe já s tim laboruju a furt nic :'(
Gréta avatar 7.11. 14:45 Gréta | skóre: 5 | blog: Grétin blogísek | Stockholm
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí
takhle se to dělá tady v online editoru
<pre class="brush: zkratka jazyku">
sem se strčí zdroják
</pre>
      	

jo a zkratky těch jazyků jsou tady hele

sem na to přišla i bez tebe a moc dobře vim že si tady včera byl ;D
xkucf03 avatar 13.11. 18:26 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí

Vtipné je, že to máš napsáno hned pod formulářem, kterým vkládáš komentáře: Nápověda k formátování (včetně těch zkratek jazyků).

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
8.11. 13:39 SkákalPřesOheňAžSiPropálilMokasíny | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí
Typicky nesvar i "zkusenych" programatoru je v tom, ze nevytvari jasne oddelene urovne abstrakce a bezne dochazi k prosakovani nizkourovnovych konstrukci do vysokourovnovych.
IMO ten problém je ještě hlubší, zobecnil bych to na dvě asumpce:
  • Existuje sada abstrakcí (a jejich rozdělení do úrovní), které je pro daný software (dostatečně) jednoznačně "správné", tj. vhodné pro všechny/mnoho usecases a z pohledu všech/mnoha lidí.
  • Je možné mít non-leaky abstrakce.
Tyhle dvě asumpce IMO nikdo neukázal jako platné, nicméně autoři mnoha úvah s nimi taknějak implicitně počítají jako s platnými...
8.11. 15:14 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí
Tyhle dvě asumpce IMO nikdo neukázal jako platné, nicméně autoři mnoha úvah s nimi taknějak implicitně počítají jako s platnými...
Chapu tvou pripominku, ale v podstate je to nirvana fallacy.
Existuje sada abstrakcí (a jejich rozdělení do úrovní), které je pro daný software (dostatečně) jednoznačně "správné", tj. vhodné pro všechny/mnoho usecases a z pohledu všech/mnoha lidí.
Abstrakce by nemely byt neco statickeho, ale neco se vytvari a rusi podle toho, jak je to potreba. Mimochodem na nizsich urovnich rozdeleni do vrstev (CPU, OS, std. knihovna, runtime, aplikacni server) funguje rozdeleni dobre, je nejaky duvod, proc by to nemelo fungovat v dalsich vrstvach?
Je možné mít non-leaky abstrakce.
Leaky abstrakce jsou problematicke, ale je to malinko neco jineho nez to, s cim asi bystroushaak zapasi a na co poukazuju ja. To jest, ze mezi programatory je zvykem michat ruzne vrstvy abstrakce jen z toho duvodu, ze je to pohodlne a pak se z ladeni stava peklo.

Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
Bystroushaak avatar 8.11. 15:28 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí
Leaky abstrakce jsou problematicke, ale je to malinko neco jineho nez to, s cim asi bystroushaak zapasi a na co poukazuju ja. To jest, ze mezi programatory je zvykem michat ruzne vrstvy abstrakce jen z toho duvodu, ze je to pohodlne a pak se z ladeni stava peklo.
To si zrovna vůbec nemyslím, že je můj problém. Můj problém je, že v debuggeru debuguji virtuální stroj, který očividně musí provést spoustu instrukcí jazyka ve kterém je napsán, aby mohl provést jednu interpretovanou instrukci. S mně dostupnými nástroji není nic, co by mi umožnilo posunout se ve "věži abstrakce" výš a debugovat v debuggeru pythonu přímo tinySelf. Například ani neexistuje možnost, jak v něm přeskakovat ten správný kus kódu v závislosti na kontextu (tj prováděná instrukce), nebo vizualizovat objekty.

To o čem mluvíš ty je, že programátoři občas používají blbé způsoby abstrakce, ze kterých není vidět co vlastně modeluješ. To o čem mluvím já je že i když použiješ dobré způsoby abstrakce (všechno vymodeluješ ve smysluplných objektech a bude to mít smysluplné kontejnery, zapouzdření a pojmenování), tak stále může ta implementace být příliš nízkoúrovňová a budeš ztrácet moc času procházením té nízkoúrovňovosti.

Analogie je, jako kdybys debuggoval interpret Pythonu v (dis)assemblerovském debuggeru, kde ani nevidíš C kód, ve kterém je ten interpret psaný. Moldable tools debugger ti umožňuje posunout abstrakci tak, abys (dis)assemblerovací debugger rozšířil tak, že bude ukazovat nejenom C, ale rovnou Python objekty a kód.

Samozřejmě, že já bych mohl a časem asi budu muset napsat custom debugger přímo pro tinySelf, ale to je klasický yak shaving ve chvíli kdy jen potřebuju odladit nějakou úplně nesouvisející chybu.
8.11. 16:33 SkákalPřesOheňAžSiPropálilMokasíny | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí
Abstrakce by nemely byt neco statickeho, ale neco se vytvari a rusi podle toho, jak je to potreba. Mimochodem na nizsich urovnich rozdeleni do vrstev (CPU, OS, std. knihovna, runtime, aplikacni server) funguje rozdeleni dobre, je nejaky duvod, proc by to nemelo fungovat v dalsich vrstvach?
Pokud vím, SmallTalkisti si stěžují i na ten OS...
Leaky abstrakce jsou problematicke, ale je to malinko neco jineho nez to, s cim asi bystroushaak zapasi a na co poukazuju ja. To jest, ze mezi programatory je zvykem michat ruzne vrstvy abstrakce jen z toho duvodu, ze je to pohodlne a pak se z ladeni stava peklo.
S tím souhlasim, ale IMO problém bývá, i když programátoři neprasí. Mnohokrát jsem viděl případ, kdy snaha vytvořit nějaké rozšíření na vyšší úrovni vede k tomu, že člověk zjistí, že vrstva/vrstvy níž něco takového nepodporuje/í (nebo blbě), takže se může stát, že musí projít napříč několika vrstavam až někam kdovíkam do střev, abys dosáhl cíle... Případně zjistí, že tohle dělat by bylo složité / nepraktické / apod., a vykašle se na to...

Snažim se vymyslet nějakej příklad. Napadá mě např. že u nějakého kompilátoru nebo něčeho, co netriviálně zpracovává nějaký vstupní formát, chceš mít typicky hezké chybové hlášky. Na to typicky potřebuješ, aby skrz celou tu věc (a její mnohé vrstvy) procházely informace o pozicích ve vstupních datech (tj. nějaké spany apod.). Pokud ta nižší vrstva (lexer) tohle nepodporuje, ostrouháš. Jiný příklad je třeba jazyk Go, který pro dobré fungování gorutin potřebuje, aby OS poskytoval epoll/kqueue/iocp nebo ekvivalent. Dnes takovéhle věci (jakože ti parser poskytuje spany a že ti OS poskytuje epoll apod.) považujeme za samozřejmé, ale to je IMO hlavně protože jsou dobře známé vlastnosti a use-cases těchto mechanismů. Oproti tomu psát do rozšiřitelných programů abstrakce pro nějaké úplně nové use-cases, které třeba vůbec neznáme, mi přijde na hranici možností.

Určitě se dá už dnes udělat spousta věcí pro to, aby software byl rozšiřitelnější a souhlasim, že lidi na to často kašlou. Nicméně bych to neházel jenom na blub programmers, jak je dobrým zvykem, započítal bych, že psát vysoce rozšiřitelný / vysoce flexibilní software je těžký.
Gréta avatar 6.11. 14:13 Gréta | skóre: 5 | blog: Grétin blogísek | Stockholm
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí
jako já vim že lulu založil spoluzakladatel redhatu ale to ještě neni nějaká záruka kvality. jsem ji teda nikdy nepoužila ale existuje nějaká knihovnička.cz kde se dá vytisknout knížka už od jednoho kusu. jako tu knihovničku hlavně používaj různý ty literární pošuci co jim žádný vydavatelství nechtělo jejich brak vydat i kdyby jim platili ale tu knížku jsem měla v rukou protože ji dostala mamka od kámošky protože ji nechtěla urazit a táta ji pak trhal listy a zatápěl s ní v kamnech že zbyly jen ty desky protože na nich byl nějakej hezkej obrázek ale pak se taky vyhodili když mamčina kámoška měla přijít na kafe. ty listy se z ní trhali blbě takže to tam asi uměj v tý knihovničce :D

btw doufám že nejseš ta mamčina kámoška protože to je tajemství ppšššššššš ;D
8.11. 20:51 .
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí
Dík za tip na čtivo.
8.11. 21:49 :
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí
Díky za typ čím si mám vytřít zadek.
10.11. 13:17 ...
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí
Takové frikulinské. Pochybuji, že autor někdy něco reálně užitečného naprogramoval.
Agent avatar 10.11. 18:07 Agent | HC city
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí
Teď si nejsem jist koho máš na mysli, jestli Andrei Chiș nebo Bystroušku
Nevěděl zpočátku, co si počít, jak žít, co dělat, ale brzy se vpravil do role samotáře.
11.11. 14:16 _
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí
Ne a lépe užto nebude.
xkucf03 avatar 13.11. 17:55 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí
Příloha:
Z programátorského hlediska prakticky vždy dává smysl vytvořit si nástroj pro práci s doménovou abstrakcí. V téměř každém eshopu se s modelem doménové abstrakce nepracuje pomocí shellu programovacího jazyka, ale pomocí nějakého grafického rozhraní. V něm je možné například zrušit objednávku kliknutím na tlačítko, či sledovat její stav.

Přitom relační databáze jsou na to jako dělané. Je to sice extrémně neobjektový přístup (data jsou striktně oddělená od chování), ale to uživatelům nemusí až tolik vadit. Mají totiž dobrý vhled přímo do dat, mají silný jazyk pro jejich procházení (SQL), funguje tam reflexe… a když chceš s daty něco udělat, tak použiješ buď standardní jazyk (DML) nebo zavoláš uloženou proceduru, která může (měla by) obsahovat dostatečnou dokumentaci toho, co dělá, a díky vhodné jmenné konvenci a strukturování (schémata) zajistíš, aby uživatel věděl, co volat.

Napsat nad tím obecné GUI není až tak těžké – máš tam information_schema, kde se dočteš vše potřebné k tomu, abys GUI pro danou doménu vygeneroval.

Někdo se možná zděsí nad tím, že by se měl uživatel hrabat přímo v databázi, ale podobně by se asi zděsil i nad tím, že by se uživatel měl hrabat v nějakých objektech a používat reflexi k tomu, aby věděl, co na nich volat za metody. Mimochodem v té databázi jsou navíc práva, takže lze pro každého uživatele/roli definovat, co může číst, měnit nebo jaké procedury/funkce může volat + se dá auditovat, kdo co dělal.

Debugger je typickou ukázkou programu, který pracuje jen na úrovni debugovaného jazyka, což může být ve spoustě případů špatná úroveň abstrakce.

Nebo řešíš úlohu pomocí nevhodného nástroje. Podle mého debugger slouží právě k hrabání se v kódu a zkoumání, jak to nízkoúrovňově funguje. Nikoli k ladění obchodní logiky. Sám debugger používám poměrně svátečně a jsou programátoři, kteří ho nepoužívají vůbec.

Obchodní logika (tzn. ty doménově specifické věci) se řeší třeba v procesním modelování a existují nástroje, které umožňují ty procesy (které sis nakreslil jako diagramy) spouštět – a kromě toho, že ten proces pak „ožije“ a stane se z něj program, tak se dá různě měřit a sledovat. To už se pak dá nazvat tím debuggerem pro obchodní logiku.

Nicméně na objekty rozpoznané v kamerových záznamech by se to nehodilo – tam se asi bez ručně napsaného nástroje neobejdeš. A dost možná bude jednodušší napsat takový jednoúčelový nástroj, než natolik obecný debugger + jeho parametrizaci pro danou doménu. Osobně taky preferuji abstraktní a obecné nástroje, ale tady mi přijde, že by náklady na vývoj obecného řešení byly asi až příliš vysoké.

Další věc je, že na produkci se moc nechceš připojovat debuggerem nebo spíš ti to ani není dovoleno, a je potřeba se spolehnout na logy.

Pak tu jsou mikroslužby, kde je aplikace rozdělená na více samostatných procesů (služeb), které spolu komunikují po síti, a na jejich propojení dohlíží nějaké běhové prostředí nebo framework. Tam pak často bývají různé nástroje na monitorování jednotlivých interakcí a trasování jednotlivých volání napříč jednotlivými službami. Ale to je všechno dost v počátcích a co jsem viděl, tak tam moc podpora pro obchodní logiku a doménově specifické věci není a jde spíš o ten technický pohled na věc. Je otázka, jestli se to k tomu časem dopracuje, nebo jestli móda mikroslužeb dřív vyprchá…

tinySelf, můj interpreter programovacího jazyka, je napsaný v restriktivní kompilované verzi pythonu. Teoreticky tedy mám možnost používat k debugování nástroje pythonu, jmenovitě například debugger pdb, či debugger zabudovaný v PyCharmu. Když ve svém jazyce objevím chybu narážím na problém, že použitý debugger pracuje na moc nízké úrovni modelovaného problému. Modeluji lexer, parser, kompilátor a interpreter bytecode. Debuger mi však nabízí pouze debugování „hmoty“, ze které je modelováno. … Když jsem se snažil tuto chybu debugovat, neustále jsem narážel na to že ve chvíli, kdy používám nástroje pythonu narážím na to že ve skutečnosti debuguji moc nízkou úroveň modelu. Aby se vykonala jedna instrukce bytecode v mém interpretru, bylo nutné projít stovky řádků kódu v pythonu jazyce. Typicky bylo třeba projít desítky instrukcí, než jsem porozuměl povaze problému. Než jsem došel do správného bodu, strávil jsem krokováním klidně půl hodiny.

Kdybys to postavil nad GraalVM, tak bys v debuggeru (ať už Netbeans nebo třeba Chromium) pracoval s konstrukty toho svého tinySelfu a ne s nějakým nízkoúrovňovým bajtkódem, do kterého se tvůj jazyk přeložil. Nízkoúrovňové optimalizace bys mohl případně řešit v IGV.

Oproti tomu existují jazyky, které umožňují definovat různé DSL a dynamicky je střídat. Například Helvetia, či REBOL, jenž umožňuje přímo přistupovat k BNF parseru a definovat do něj nové gramatiky.

Tohle je věc vkusu a osobních preferencí, ale podle mého už to příliš zvyšuje složitost jazyka/syntaxe a nároky na toho, kdo má kód číst a porozumět mu. Kromě standardních jazykových konstrukcí se musíš naučit i ty doménově specifické – a dostat se z kódu k jejich definicím bývá těžší, než se v IDE prokliknout třeba na definici metody nebo anotace a přečíst si tam jejich dokumentaci. Opačný extrém je Go, které podle mého trpí zase přehnanou snahou o zjednodušení jazyka.

Autor v knize zkoumá různé možnosti, jak je typicky dosahováno rozšiřitelnosti. Například se věnuje různým architekturám aplikací, a jak jsou v nich vytvářeny pluginy. Mimo jiné probírá a analyzuje integrace pluginů vůči standardnímu API, použití konektorů, či message busu. Zkoumá také skládatelnost aplikací ve stylu unixu. Na různých studiích s reálnými uživateli ukazuje, jak moc je náročné vytvoření pluginu a rozšíření funkcionality komponenty.

Tohle jsem teď shodou okolností řešil v relpipe-in-filesystem. Přemýšlel jsem, jaká všechna data by to mělo mělo být schopné ze souborů vytěžit (umělo to takový ten základ jako velikost soubru, vlastníka, symlinky, rozšířené atributy atd.) a nakonec jsem se rozhodl místo rozšiřování funkcionality (což zvyšuje komplexitu a obvykle přidává závislosti na nějakých knihovnách) tam dát jen obecné rozhraní pro spouštění vlastních skriptů a přidat jen pár příkladů (PDF metadata, MIME typy, XPath…). Takže si napíšeš skript/program na pár řádků v libovolném jazyce a ten ze souborů vytahá atributy, které potřebuješ (klidně i doménově specifické). Ale ještě to budu trochu předělávat – jednak aby to využilo vícejádrové procesory (tzn. forknout víc procesů) a jednak opakovaně používat jeden proces skriptu pro více atributů a záznamů (tzn. jinde naopak ten fork()/exec() nedělat tak často).

Inspector umožňuje objektům definovat jak se mají zobrazit přidáním speciálních metod do objektu. Cosi jako .__repr__() či .__str__() (nebo .toString()), ale pro user interface inspectoru, či debuggeru, nebo spotteru.

Tady je otázka, jestli tento ladící kód má být součástí zdrojáků nebo zda má být dodaný zvenku. Na jednu stranu to takhle funguje automaticky a nemusíš nic konfigurovat, ale na druhou stranu to znečišťuje produkční kód a taky to závisí na autorovi – když to bude cizí knihovna, tak si budeš muset její třídy podědit nebo nějak upravit za běhu, abys to tam doplnil. Případně může mít jeden objekt resp. třída více možných využití a každý bude chtít jinou reprezentaci v debuggeru.

Pro textový výstup tohle běžně jde – viz příloha. Zajímavý je ten grafický výstup. Případně volání metod (i když na to stačí běžná reflexe třeba v Javě).

Spotter nabízí cosi jako search engine pro jednotlivé objekty

Tohle zase připomíná OQL (náhodný článek z roku 2005, nebo Eclipse, IBM).

Zde je například možné vidět debugger pro parser … Typické rozšíření se skládá z doménově-specifikých debugovacích operací a doménově-specifického pohledu, přičemž oboje je založeno na debugovací session. … Developeři můžou vytvářet doménové abstrakce pomocí:

Tohle už je zajímavější.

Pokud vás zajímá, jak budou vypadat vývojářské nástroje za dvacet let, a případně se chcete podílet na této snaze už nyní, rozhodně doporučuji knihu k přečtení.

Co mi tam chybí (nicméně četl jsem jen tvůj článek, ne tu knihu), je jakákoli podpora asynchronního programování a systémů založených na poslínální zpráv. Ono ladit synchronní kód je ještě relativně jednoduché a většinou ani není potřeba ho ladit – stačí si ho přečíst. Ale daleko obtížnější bývá pracovat s asynchronním kódem, kde se např. na jedné straně programu zadá nějaký vstup nebo pošle nějaká zpráva do fronty a na druhé straně programu se (kdykoli v blíže neupřesněné budoucnosti) něco stane, aniž by tam byla nějaká na první pohled zřejmá vazba (jako např. že jedna metoda volá druhou).

Je otázka, jestli budou dřív běžně dostupné nástroje pro ladění asynchronního kódu, nebo spíš jazykové prostředky, které umožní psát (ve výsledku) asynchronní a neblokující kód přímočarým až naivním synchronním způsobem. Viz Fibers v Javě.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
včera 02:40 SkákalPřesOheňAžSiPropálilMokasíny | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí
Je otázka, jestli budou dřív běžně dostupné nástroje pro ladění asynchronního kódu, nebo spíš jazykové prostředky, které umožní psát (ve výsledku) asynchronní a neblokující kód přímočarým až naivním synchronním způsobem. Viz Fibers v Javě.
Hm, takže v podstatě chtějí v Javě to samé, co dělá Go.

Je zajímavé, že na konci si všimli tohohle:
Continuations and fibers dominate async/await in the sense that async/await is easily implemented with continuations (in fact, it can be implemented with a weak form of delimited continuations known as stackless continuations, that don't capture an entire call-stack but only the local context of a single subroutine), but not vice-versa.
... přesně takhe totiž funguje asynchronní programování v Rustu, kde vzhledem k zaměření jazyka na výkon chtěli právě ty stackless continuations (a na nich je postaveno async/await tak, jak popisují).

V každém případě explicitní podpora ze strany debuggeru je stále potřeba, i když máš podporu asynchronního programování v jazyce.
Bystroushaak avatar včera 23:44 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí
Z programátorského hlediska prakticky vždy dává smysl vytvořit si nástroj pro práci s doménovou abstrakcí. V téměř každém eshopu se s modelem doménové abstrakce nepracuje pomocí shellu programovacího jazyka, ale pomocí nějakého grafického rozhraní. V něm je možné například zrušit objednávku kliknutím na tlačítko, či sledovat její stav.
Přitom relační databáze jsou na to jako dělané.
*Vyprskne*

Tady jde taky o to, že je to pořád lowlevel přístup, kde se něco děje v textu a ty to modelování musíš ve skutečnosti pořád dělat ve své vlastní hlavě. Což většina lidí zvládne cca s 7+-2 proměnnými (viz Millerovo magické číslo) na jedné úrovni abstrakce. Pak musíš buďto tvořit vnořené hierarchie (kterých si ale lidi zase zvládnou zapamatovat cca 7+-2), nebo přejít na jiné části mozku než symbolické, tedy typicky grafické reprezentace, kde mozek nemá problém sledovat stovky proměnných a jejich stavů.
Nebo řešíš úlohu pomocí nevhodného nástroje. Podle mého debugger slouží právě k hrabání se v kódu a zkoumání, jak to nízkoúrovňově funguje. Nikoli k ladění obchodní logiky. Sám debugger používám poměrně svátečně a jsou programátoři, kteří ho nepoužívají vůbec.
Slouží k tomu, protože k tomu slouží, ne protože by nějaké omezení v realitě diktovalo, že to tak má být. Představ si třeba jak by mohlo být užitečné moct krokovat skrz abstraktní doménový model a například sledovat co konkrétně zákazník v eshopu dělal jako kdybys mu koukal přes rameno.
Obchodní logika (tzn. ty doménově specifické věci) se řeší třeba v procesním modelování a existují nástroje, které umožňují ty procesy (které sis nakreslil jako diagramy) spouštět – a kromě toho, že ten proces pak „ožije“ a stane se z něj program, tak se dá různě měřit a sledovat. To už se pak dá nazvat tím debuggerem pro obchodní logiku.
Zaměřuješ se na moc velké implementační detaily. To byla jen analogie schválně vybraná tak, aby jí pochopil každý kdo to bude číst, protože každý má zkušenost s eschopem a dokáže si ty vztahy tam představit. V praxi samozřejmě jde o naprosto libovolný příklad, kde můžeš uvažovat třeba objekty v mém tinySelfu, kde se do toho navíc zapojují různé procesy a stacky a kde co.
A dost možná bude jednodušší napsat takový jednoúčelový nástroj, než natolik obecný debugger + jeho parametrizaci pro danou doménu. Osobně taky preferuji abstraktní a obecné nástroje, ale tady mi přijde, že by náklady na vývoj obecného řešení byly asi až příliš vysoké.
Tak třeba v pythonu ti nic jiného ani nezbyde. Ale kdyby to bylo psané ve smalltalku, hodně by mě zajímalo kam by se dalo zajít s moldable debuggerem a jaké by měl limitace.
Tohle je věc vkusu a osobních preferencí, ale podle mého už to příliš zvyšuje složitost jazyka/syntaxe a nároky na toho, kdo má kód číst a porozumět mu. Kromě standardních jazykových konstrukcí se musíš naučit i ty doménově specifické – a dostat se z kódu k jejich definicím bývá těžší, než se v IDE prokliknout třeba na definici metody nebo anotace a přečíst si tam jejich dokumentaci. Opačný extrém je Go, které podle mého trpí zase přehnanou snahou o zjednodušení jazyka.
Souhlasím, osobně se mi to moc nelíbilo.
Kdybys to postavil nad GraalVM, tak bys v debuggeru (ať už Netbeans nebo třeba Chromium) pracoval s konstrukty toho svého tinySelfu a ne s nějakým nízkoúrovňovým bajtkódem, do kterého se tvůj jazyk přeložil. Nízkoúrovňové optimalizace bys mohl případně řešit v IGV.
Jo, vím o tom, i když zrovna IGV jsem úplně nepobral, přišlo mi to jako solidní bordel, který jsem si ale už několikrát u rpythonu přál. Tam se sice dá použít na JIT divná vizualizace skrz pygame, ale prase aby se v tom vyznalo.
ale na druhou stranu to znečišťuje produkční kód a taky to závisí na autorovi
Osobně si nemyslím že zrovna definice __repr__ či __str__ nějak znešišťuje produkční kód. Naopak to umožňuje mnohem jednodušeji pochopit co se tam vlastně děje. Jinak ve Smalltalku je možné injectovat metody do objektů i po jejich vytvoření a použití, takže je možné třeba distribuovat zvlášť balíček, který by mé objekty rozšířil o tyhle metody. To se mi zdá jako docela dobré řešení.
Tohle zase připomíná OQL (náhodný článek z roku 2005, nebo Eclipse, IBM).
Je dost možné že autor to tam referencuje. Na Eclipse se konkrétně odkazuje několikrát, tedy na studie které vedly ke konkrétním featurám Eclipse.
Tohle jsem teď shodou okolností řešil v relpipe-in-filesystem. Přemýšlel jsem, jaká všechna data by to mělo mělo být schopné ze souborů vytěžit (umělo to takový ten základ jako velikost soubru, vlastníka, symlinky, rozšířené atributy atd.) a nakonec jsem se rozhodl místo rozšiřování funkcionality (což zvyšuje komplexitu a obvykle přidává závislosti na nějakých knihovnách) tam dát jen obecné rozhraní pro spouštění vlastních skriptů a přidat jen pár příkladů (PDF metadata, MIME typy, XPath…). Takže si napíšeš skript/program na pár řádků v libovolném jazyce a ten ze souborů vytahá atributy, které potřebuješ (klidně i doménově specifické). Ale ještě to budu trochu předělávat – jednak aby to využilo vícejádrové procesory (tzn. forknout víc procesů) a jednak opakovaně používat jeden proces skriptu pro více atributů a záznamů (tzn. jinde naopak ten fork()/exec() nedělat tak často).
Cool.
dnes 00:26 SkákalPřesOheňAžSiPropálilMokasíny | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Moldable tools; kniha a hnutí
Představ si třeba jak by mohlo být užitečné moct krokovat skrz abstraktní doménový model a například sledovat co konkrétně zákazník v eshopu dělal jako kdybys mu koukal přes rameno.
Viz Time travelling debugger ... což stále ještě není úplně to co chceš - je to stále víceméně jedna úroveň abstrakce, ale je to IMO krok tím směrem...

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.