Dnes a zítra probíhá vývojářská konference Google I/O 2025. Sledovat lze na YouTube a na síti 𝕏 (#GoogleIO).
V Bostonu probíhá konference Red Hat Summit 2025. Vybrané přednášky lze sledovat na YouTube. Dění lze sledovat na síti 𝕏 (#RHSummit).
Společnost Red Hat oficiálně oznámila vydání Red Hat Enterprise Linuxu 10. Vedle nových vlastností přináší také aktualizaci ovladačů a předběžné ukázky budoucích technologií. Podrobnosti v poznámkách k vydání.
Tuto sobotu 24. května se koná historicky první komunitní den projektu Home Assistant. Zváni jsou všichni příznivci, nadšenci a uživatelé tohoto projektu. Pro účast je potřebná registrace. Odkazy na akce v Praze a v Bratislavě.
Troy Hunt představil Have I Been Pwned 2.0, tj. nový vylepšený web služby, kde si uživatelé mohou zkontrolovat, zda se jejich hesla a osobní údaje neobjevily v únicích dat a případně se nechat na další úniky upozorňovat.
Microsoft představil open source textový editor Edit bežící v terminálu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
V Seattlu a také online probíhá konference Microsoft Build 2025. Microsoft představuje své novinky. Windows Subsystem for Linux je nově open source. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Z příspěvku Turris Sentinel – co přinesl rok 2024 na blogu CZ.NIC: "Za poslední rok (únor 2024 – únor 2025) jsme zachytili 8,3 miliardy incidentů a to z 232 zemí a z jejich závislých území. Tyto útoky přišly od 6,2 milionu útočníků (respektive unikátních adres). SMTP minipot je stále nejlákavější pastí, zhruba 79 % útoků bylo směřováno na tento minipot, 16 % útoků směřovalo na minipot Telnet, 3 % útoků směřovaly na minipot HTTP a 2 % na minipot FTP. Dále jsme zaznamenali 3,2 milionu unikátních hesel a 318 tisíc unikátních loginů, které útočníci zkoušeli."
Byla vydána (Mastodon, 𝕏) nová verze 3.0.4 svobodné aplikace pro úpravu a vytváření rastrové grafiky GIMP (GNU Image Manipulation Program). Přehled novinek v oznámení o vydání a v souboru NEWS na GitLabu. Nový GIMP je již k dispozici také na Flathubu.
Byla vydána nová stabilní verze 7.4 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 136. Přehled novinek i s náhledy v příspěvku na blogu.
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