O víkendu probíhá konference OpenAlt 2025. Na programu je spousta zajímavých přednášek. Pokud jste v Brně, stavte se. Vstup zdarma.
Josef Průša představil novou velkoformátovou uzavřenou CoreXY 3D tiskárnu Prusa CORE One L a nový open source standard chytrých cívek OpenPrintTag i s novou přepracovanou špulkou.
Na GOG.com běží Autumn Sale. Při té příležitosti je zdarma hororová počítačová hra STASIS (ProtonDB: Platinum).
Ubuntu 25.10 má nově balíčky sestavené také pro úroveň mikroarchitektury x86-64-v3 (amd64v3).
Byla vydána verze 1.91.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
Ministerstvo průmyslu a obchodu vyhlásilo druhou veřejnou soutěž v programu TWIST, který podporuje výzkum, vývoj a využití umělé inteligence v podnikání. Firmy mohou získat až 30 milionů korun na jeden projekt zaměřený na nové produkty či inovaci podnikových procesů. Návrhy projektů lze podávat od 31. října do 17. prosince 2025. Celková alokace výzvy činí 800 milionů korun.
Google v srpnu oznámil, že na „certifikovaných“ zařízeních s Androidem omezí instalaci aplikací (včetně „sideloadingu“) tak, že bude vyžadovat, aby aplikace byly podepsány centrálně registrovanými vývojáři s ověřenou identitou. Iniciativa Keep Android Open se to snaží zvrátit. Podepsat lze otevřený dopis adresovaný Googlu nebo petici na Change.org.
Byla vydána nová verze 18 integrovaného vývojového prostředí (IDE) Qt Creator. S podporou Development Containers. Podrobný přehled novinek v changelogu.
Cursor (Wikipedie) od společnosti Anysphere byl vydán ve verzi 2.0. Jedná se o multiplatformní proprietární editor kódů s podporou AI (vibe coding).
Google Chrome 142 byl prohlášen za stabilní. Nejnovější stabilní verze 142.0.7444.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 20 bezpečnostních chyb. Za nejvážnější z nich bylo vyplaceno 50 000 dolarů. Vylepšeny byly také nástroje pro vývojáře.
Rad bych vedel, zda nekdo pouziva nejake vyvojove prostredi pro rozsahlejsi informacni systemy, tedy nejen pro ucetnictvi ale i pro vyrobu a pod. Je jedno jestli privatne nebo v zamestnani.
Pod vyvojovym prostredim si ovsem nepredstavuji eclipse nebo neco podobneho, tedy nejaky nadupany editor, ktery nabizi parametry funkci nebo vlastnosti nejakych trid a ma treba i integrovane spousteni kompileru a debugeru. Myslim spise na neco, co uz ma napr. funkce pro sklad, zalozeni nove zakazky apod. tedy funkce svazane s aplikaci. K tomu to obecnejsi, napr. generator vystupu.
Vim, ze existuji systemy (compiere, tinyerp), ktere jsou otevrene a je mozno je vyuzit. Ale mam pocit, ze toto neni spravna cesta - filosofie, ktera se za timto postupem skryva je, "vezmi to, co jsme vymysleli a jestli chces zmeny, tak se hrabej v tech zdrojacich".
Pripada mi divne, ze zadny takovy system nemohu najit - ani ke koupi, ani free. Zatim se vsichni vrhaji na nejake konkretni ucetnictvi, ale kdyz ma dojit na zmeny , tak je nikdo nechce a ani nemuze delat.Rad bych se tedy zeptal, nebylo by lepsi mit spise nastroj na vyrobu tech ucetnictvi, nez ta ruzna ucetnictvi, ve kterych se musim eventuelne s rizikem hrabat, kdyz chci neco zvlastniho. proc takovy system neexistuje. Nebo nekdo neco takoveho zna?
Tiskni
Sdílej:
26.5.2006 19:34
JiK | skóre: 13
| blog: Jirkoviny
| Virginia
) a generování GUI napůl dynamicky a přitom do čitelného kódu. Některé operace budou trošku nestandardní (customized fulltext v texové databázi), relační databáze se mi do toho proto moc tahat nechce, objekty tohle řeší líp. Prevalence by ta data měla zvládnout, tím se vyřeší tři čtvrtě problémů.
Klient desktopový, zabalený do Starkitu, který si bude ze serveru tahat taky generované GUI (aktualizace klienta: řeší se samy. ). Řekněme, že Tk pro mé účely má jisté výhody (oproti jiným řešením) a na cílové platformě, která nebude unixová, nemusím tolik řešit vzhled, na jehož vylepšení se v unixovém Tk teprve pracuje. Jsem holt minimalista. Jestli klient bude mít mega a půl a server čtyři mega (oboje celkem), bude to hodně a přitom to bude kompletní. 
Je pravda, že překladatelská knowledge base nemá s účetnictvím moc společného, ale pro mně je to pracovní IS. 
Tahle technologie vznikla v první polovině 90. let přesně za tímhle účelem a evidentně funguje, lidi v tom takové aplikace dělají. Kromě toho, pokud spuštění aplikace bude trvat pár sekund, tak se snad nic neděje. Spousta aplikací se spouští pár sekund. Co přesně máte na mysli tou "maskou"? Měla by to být aplikace pro cca. 10-15 lidí s důrazem na retrieval textových dat.
I kdyz bude cela databaze "nejak" (co je nejak je zde ta otazka) odstinena, tak jsem zjistil, ze vetsina uzivatelu nejak intuitivne chce si v nejhorsim pripade na ta data "sahnout" ve vlastni rezii.
K tomu clientu - to je pro me jeden ze stavebnich kamenu toho vyvojoveho prostredi. Domnival jsem se, ze chapu co chcete delat, ale ted si nejsem jisty. Proto moje predstava:
- client je nejake exe a toto exe nema v sobe po startu zadnou aplikacni logiku - start muze trvat i nekolik sekund
- exe si natahne po startu z serveru nejake menu a vse ostatni potrebne
- uzivatel si vybere v menu nejakou polozku a klikne na ni
- v tuto chvili to exe natahne ze servru nejaky popis a na obrazovce se objevi to, cemu rikam "maska". Maska je tedy jedno z mnoha oken te aplikace. V tomto okne je tech 500 elementu (widgetu) a doba od toho kliknuti az k uplnemu zobrazeni toho okna by nemala presahovat 0.7 sekundy.
je vas postup podobny, nebo na to jdete jinak
.
BTW, „Neplatí, že OODB -> nonSQL“ – nevím, no, psát definice tříd, generické funkce (v primitivnějších jazycích „rozhraní“), vytvářet z objektů složité datové struktury, používat kontejnerové třídy s libovolnými algoritmy - to už v SQL jde? Jestli SQL 2003 fakt takhle vychytali, tak to se na něj budu muset podívat.
BTW, „Neplatí, že OODB -> nonSQL“ – nevím, no, psát definice tříd, generické funkce (v primitivnějších jazycích „rozhraní“), vytvářet z objektů složité datové struktury, používat kontejnerové třídy s libovolnými algoritmy - to už v SQL jde? Jestli SQL 2003 fakt takhle vychytali, tak to se na něj budu muset podívat.
Napsal jsem to blbě. Spíš tam měly být objektově-relační DB. Na druhou stranu jsou dnes ORDB používané více než čisté OODB... Přes úpadek aspoň dodám, že některé OODB se snaží podporovat i SQL, kvůli klasickým relačním úlohám, které jsou v nich hůře popsatelné (slušně shrnuté to je třeba ve Wiki).
SQL 2003 vychytávají spíše směrem k SQL/XML (paper).
„Additionally, object databases lack a formal mathematical foundation, unlike the relational model, and this in turn leads to weaknesses in their query support.“Upřímně, já nevím, co se pánům nelíbí, ty chybějící „formální matematické základy“ mi přijdou jako FUD. Řádkové zamykání a řešení deadlocků v reálných implementacích – to jako podle nich má být ta „formálně lépe vyřešená“ věc? V tu chvíli je mi je matematicky čistý koncept relačního kalkulu naprd, když si díky takové věci jako je neexistence identit vynucuje takovéhle nesmysly...
Podotýkám, že teorie pana Codda mi nesmrdí, jen vidím kolem sebe hromadu „SQL fanatismu“, aspoň mi to tak přijde.
„Database-centric thinking tends to view the world through a declarative and attribute-driven viewpoint, while OOP tends to view the world through a behavioral viewpoint.“To už mi přijde jako dost velký nesmysl, protože objektová databáze může sama o sobě deklarativní přístup obsáhnout, není s ním v jakémkoli rozporu. Ale možná je to tím, že pojem „objektová databáze“ chápu trošku šířeji, asi jako Lisp a jiné jazyky mimo mainstream chápou o dost obecněji pojem „objekt“...
To už mi přijde jako dost velký nesmysl, protože objektová databáze může sama o sobě deklarativní přístup obsáhnout, není s ním v jakémkoli rozporu.Nesmysl to podle mě není. Autor netvrdí, že objektová databáze deklarativní přístup neobsahuje, jen poukazuje na problém s přístupem k datům kvůli zapouzdření (querying on data content vs. predefined access paths). A v podstatě má pravdu, když říká, že objektové systémy jsou vystavěny na chování objektů. Na nutné (!?) deklarativní "zlo" lze nahlížet i jako na přežitek ze světa primitivních typů, ale to už odbočuji.
Ale možná je to tím, že pojem „objektová databáze“ chápu trošku šířeji, asi jako Lisp a jiné jazyky mimo mainstream chápou o dost obecněji pojem „objekt“...To už mi došlo, když jsi psal o generických funkcích a podvědomě asi ještě mnohem dříve (jak tě tak z diskusí znám
). Smalltalk je mainstream?
Objektová databáze mi umožní udělat si na míru deklarativně popsaný sytém, relační databáze by mi díky vazbě většiny RDBMS na SQL vnutila jeden konkrétní, poměrně rigidní, který by mi pro slušnou část dat ještě ke všemu nevyhovoval a já bych musel dělat separátní data ještě mimo databázi (vlastní fulltextová indexace a spol) a ještě to celé lepit dohromady v několika backendech a starat se o udržování konzistence...kdepak, děkuji, nechci. Prevalence to obslouží mnohem líp, dokud to nebude moc velké. To se hned tak nestane, ale pružnost budu potřebovat úplně od začátku (pár klasických tabulek, nějaký ten hypertext, fulltextový index, dost možná konfigurovatelný, hierarchické slovníky...). Prostě věřím, že dlouhodobě se mi v tom bude dělat příjemněji. A člověk se aspoň něčemu přiučí.
. Možná jsi mohl být konkrétnější ohledně ztraceného významu, protože pokud jde o čistě deklarativní záležitosti, tak by relační model měl stačit. Že to nebude tak pohodlné jako objektový přístup, by mohla vyvážit vyspělost (doplň si aspoň 5 omílaných rysů jako robustnost, škálovatelnost... ne, nechi je shazovat) RDBMS. Ale možná bych být tebou uvažoval i o objektově-relačním systému. Co se vůbec chystáš použít? Jestli to není tajné, nebo doma vypěstované.
Nevím, no, jak moc dobře se z SQL – nebo ještě lépe z existující databáze – dají generovat rozumné formuláře? Třeba Ruby on Rails řeší problém „řešit každý problém na jednom místě“, ale hopsání mezi editorem struktury databáze a definicí třídy mě taky moc neuspokojilo. Asi jsem moc náročnej... Budu taky mít testovací vektor v podobě poměrně slušného množství překladů (šlohnutých z databází Microsoftu, ke kterým mám login ) a pokusím se zreprodukovat fuzzy matching TRADOSovské konkordance, když to bude poskytovat podobné nebo ještě lepší výsledky, ovšem nad daty z naší databáze s custom poli (autor termínu, historie změn, věrohodnost překladu), ušetří nám to integrací hromadu času a práce při překladech. Fakt nevím, jak bych to mapoval nad SQLkem, přijde mi to jako lámání přes koleno.
. Prevayler nicméně vypadá velmi zajímavě. Ach jo, asi bych Tě měl blokovat - je zkouškové! Ale Scalability Test si zkusím.
v poslednej dobe sa mi zapacil OpenLaszlo, snad ma jeho existencia konecne dokope k dotiahnutiu svojho gui projektu do konca
ale viac ma do debaty o uzivatelskej privetivosti nedostanete. moj nazor je, ze design maju robit netechnici pre netechnikov, a technici - programatori vymysliet cestu, ako to vyrobit, nie ako to "osidit" (predsa len slusnejsie ako slovenske "oj*")
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz