Red Hat řeší bezpečnostní incident, při kterém došlo k neoprávněnému přístupu do GitLab instance používané svým konzultačním týmem.
Immich byl vydán v první stabilní verzi 2.0.0 (YouTube). Jedná se o alternativu k výchozím aplikacím od Googlu a Applu pro správu fotografií a videí umožňující vlastní hosting serveru Immich. K vyzkoušení je demo. Immich je součástí balíčků open source aplikací FUTO. Zdrojové kódy jsou k dispozici na GitHubu pod licencí AGPL-3.0.
Český telekomunikační úřad vydal zprávy o vývoji cen a trhu elektronických komunikací se zaměřením na rok 2024. Jaká jsou hlavní zjištění? V roce 2024 bylo v ČR v rámci služeb přístupu k internetu v pevném místě přeneseno v průměru téměř 366 GB dat na jednu aktivní přípojku měsíčně – celkově jich tak uživateli bylo přeneseno přes 18 EB (Exabyte). Nejvyužívanějším způsobem přístupu k internetu v pevném místě zůstal v roce 2024 bezdrátový
… více »Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-10-01. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Jedná o první verzi postavenou na Debianu 13 Trixie.
Byla vydána nová verze 4.6 svobodného notačního programu MuseScore Studio (Wikipedie). Představení novinek v oznámení v diskusním fóru a také na YouTube.
Společnost DuckDuckGo stojící za stejnojmenným vyhledávačem věnovala 1,1 milionu dolarů (stejně jako loni) na podporu digitálních práv, online soukromí a lepšího internetového ekosystému. Rozdělila je mezi 29 organizací a projektů. Za 15 let rozdala 8 050 000 dolarů.
Svobodný multiplatformní herní engine Bevy napsaný v Rustu byl vydán ve verzi 0.17. Díky 278 přispěvatelům.
Bylo vydáno openSUSE Leap 16 (cs). Ve výchozím nastavení přichází s vypnutou 32bitovou (ia32) podporou. Uživatelům však poskytuje možnost ji ručně povolit a užívat si tak hraní her ve Steamu, který stále závisí na 32bitových knihovnách. Změnily se požadavky na hardware. Leap 16 nyní vyžaduje jako minimální úroveň architektury procesoru x86-64-v2, což obecně znamená procesory zakoupené v roce 2008 nebo později. Uživatelé se starším hardwarem mohou migrovat na Slowroll nebo Tumbleweed.
Ministerstvo průmyslu a obchodu (MPO) ve spolupráci s Národní rozvojovou investiční (NRI) připravuje nový investiční nástroj zaměřený na podporu špičkových technologií – DeepTech fond. Jeho cílem je posílit inovační ekosystém české ekonomiky, rozvíjet projekty s vysokou přidanou hodnotou, podpořit vznik nových technologických lídrů a postupně zařadit Českou republiku mezi země s nejvyspělejší technologickou základnou.
… více »Radicle byl vydán ve verzi 1.5.0 s kódovým jménem Hibiscus. Jedná se o distribuovanou alternativu k softwarům pro spolupráci jako např. GitLab.
Jsem zakladatelem tohoto portálu. Linux jsem používal spousty let, nějaký čas jsem se aktivně podílel na jeho propagaci v Česku (CZLUG, časopisy ComputerWorld, Network Magazine atd). Se současným Abíčkem už nemám nic společného.
Zajímá mě váš názor a zkušenosti, v čem vyvíjet webové aplikace? Java má výhodu, že je strong typed a je pro ni hromada knihoven. Deployment je ale složitější, špatně se nahrávají na server změny. Dále je problém v dostupnosti programátorů. U linuxáků je obvzláště neoblíbená. Dále jsem znal PHP, kde lidí dělajících v PHP je hromada, ale bohužel procento programátorů je mezi nimi celkem nízké. Zajímavé jsou ještě ruby (on rails) a python (django). Co byste vybrali? Důležitá je efektivita vývoje. A v čem se vlastně vyvíjejí větší české projekty? Jak jsem psal, máme něco v merku. Chci (si) dokázat, že Abíčko nebyla náhoda.
Tiskni
Sdílej:
Chci (si) dokázat, že Abíčko nebyla náhoda.No jo, ale co ta zmínka z minulého blogu o tom, že podníkání "vyžaduje 100% nasazení a soustředění?"
Proto to nebude podnikání, ale časové omezený krátkodobý projekt.A co si pocnu tie tisice ludi ktore na nom zacnu byt zavisle ?
Deployment je dobre navrzeny, ale pro uplne jine zadani - jednoduche skriptovani pro jednoduche stranky.Máme asi jiná hodnotící kritéria, podle mě je pro tento účel CGI navrženo daleko lépe. Ale je to subjektivní hodnocení, vycházející z mojí vlastní praxe.
Dnes to mozna bude znit neuveritelne, ale proti psani CGI skriptu v perlu kvuli kazde volovine bylo php velke zlepseni.Tak se kvůli každé volovině napíše
Gmail je napisany v Jave. Wikipedia je napisana v PHP. Mnohe casti Google.com su napisane v Pythone Slashdot je napisany v PERLe. Twitter je napisany v RUBY. Stackoverflow je napisany v C#. A tak dalej...Ako vidis, niet najlepsieho jazyka... Jazyk totiz je len nastroj na tvoje myslienky a tie dokazes urobit v hocicom...
Neni pak problem hrat si s vecmi jako je perzistentni spojeni s DB, cachovani apod.Jenže proč vynalézat kolo a řešit tyhle základní věci, které jsou jinde už hotové a stačí je použít? Člověk se pak může víc soustředit na vlastní aplikaci.
Jenže proč vynalézat kolo a řešit tyhle základní věci, které jsou jinde už hotové a stačí je použít?Například?
Django není dokonalý, ale velice příjemný framework s ochotnou komunitou. Určitě doporučuju.
Proč by deployment nebyl plynulý? Když chcete hosting, kupte si ho u webfaction nebo djangoeurope, není to drahé a dostanete u nás nevídané služby, jako shell nebo postgres. Během pár minut můžete být online klikáním myší.
SELECT sum(cena*mnozstvi) FROM zbozi WHERE datum BETWEEN ? AND ?;a pak je mi jedno, jestli je nad tím PHP, Python, Java nebo cokoli jiného.
:a
, :b
). Dotaz se pak naparametrizuje pomocí metody, např. setString(1, $_GET("jmeno"))
, a ať uživatel do GET parametru zadá cokoli, máme jistotu, že nám SQL dotaz nerozbije.
P.S. jednou mi dokonce někdo tvrdil, že SQL je špatné, protože tam jsou SQL injekce, a že mám používat noSQL databáze, protože tam nejsou sql = ("UPDATE %s SET %s = %%s, %s = %%s WHERE %s = '%s'"%(self.db_table,self.blob_column,self.size_column,self.fname_column,name)) self.cursor.execute(sql, (binary, size))kod na vlozeni obrazku do databaze, protoze to django nativne neumi. Je to uplne stejne snadne jako v php.
nějak si s tím pohrajuPak je potřeba místo SQL vybrat jiný, dostatečně silný a pohodlný, prostředek.. Právě "raw sql" jsem se chtěl primárně vyhnout.
+1
PHP .. ano, tenhle skriptovací jazyk je poměrně jednoduchýTak na použití mi přijde tento CGI-like deployment (u PHP asi nejčastější), daleko složitější než CGI skripty v jakémkoli běžně používaném skriptovacím jazyce.
v čem vyvíjet webové aplikace?IMHO zalezi na tom, jake ... u malych (MVC s par use case) je IMHO vcelku jedno, co to bude, zkratka to, co clovek umi
Zni jako dobrej pristup.
Jenom doplnim, ze v dnesni dobe se snadno muze stat, python nebo ruby budou levnejsi, ac jsou pomalejsi, pac cas programatora stoji min jak koupit dalsi tri servery.
v cem vyvijeji velke firmy sve stranky.Z mých zkušeností je to v pořadí popularity java, .net, php.
Java má výhodu, že je strong typed a je pro ni hromada knihoven. Deployment je ale složitější, špatně se nahrávají na server změny.Deployment se v optimálním případě dělá jedním příkazem, a je dost jedno v jakém jazyce je to celé napsáno.
Dále je problém v dostupnosti programátorů. U linuxáků je obvzláště neoblíbená. Dále jsem znal PHP, kde lidí dělajících v PHP je hromada, ale bohužel procento programátorů je mezi nimi celkem nízké.Nezávisle na tom jaký zvolíte jazyk bych se na OS vůbec nedíval. Všechna jmenovaná prostředí jsou více-méně multiplatformní a webový server na kterém to pojede je také multiplatformní. Mnohem víc se vyplatí sehnat pořádného programátora a naučit ho nějaký OS než naopak.
Co byste vybrali?Nevěřím na žádné "jeden jazyk vládne všem, jeden všem jim káže…"
Upřesním:
pod složitým deploymentem si představuji javu, kde mám vycheckoutovaný adresář se zdrojáky, ten musím zbuildovat a výsledek nahrát do aplikačního serveru, který (někdy) musím restartovat. Těžko ale říci, jak to bude vypadat u jiných programovacích jazyků. I u skriptovaného PHP je asi dobré odpojit deploy adresář od checkoutu, aby se uživatelům zbytečně neobjevovaly .scm adresáře (nebo je skrýt v apachi).A co je jednodušší než
git pull mvn clean deployNebo snad chcete říct že byste rád dělal deployment tak, že prostě vyeditujete pár .php souborů pod rukama běžícího serveru?
Designerovi těžko mohu dát do ruky freemarker šablony nebo rozsekané jsp.Tohle nechápu - šablony jsou právě od toho aby se dávaly do ruky designérům. To že je někde napsáno něco jako
$obsahčlánku
to dnešní designery nerozhodí.
Nebo snad chcete říct že byste rád dělal deployment tak, že prostě vyeditujete pár .php souborů pod rukama běžícího serveru?To je na PHP běžný standard.
svn up && ant
. Nicméně mám exploaded war. A je nutné restartovat jetty, když se mění java.
pod složitým deploymentem si představuji javu, kde mám vycheckoutovaný adresář se zdrojáky, ten musím zbuildovat a výsledek nahrát do aplikačního serveru, který (někdy) musím restartovat. Těžko ale říci, jak to bude vypadat u jiných programovacích jazyků. I u skriptovaného PHP je asi dobré odpojit deploy adresář od checkoutu, aby se uživatelům zbytečně neobjevovaly .scm adresáře (nebo je skrýt v apachi).Ať už vybereš cokoli, navrhuju zautomatizovat. U svých věcí používám make a shell skripty plus mínus nějaké to awk, které pravděpodobně v budoucnu nahradím perlem.
u abíčka jsem měl problém, že javy se každý bojí. Designerovi těžko mohu dát do ruky freemarker šablony nebo rozsekané jsp. Ideální je, pokud mohu provozní věci (třeba úpravy designu nebo nasazení reklam) delegovat do rukou někomu cizímu, kdo nemusí být programátor. Robert to zvládal, ale IMHO byl světlá výjimka.Joo, doupravování šablon je velký problém... zatím jsem byl jenom u metody, kdy se vezme statická stránka, v té se udělají úpravy, a programátor ty úpravy dolepí do šablon. Pořád jsem se poohlížel po šablonovacím systému, ke kterému budou nástroje pro designéry.
Joo, doupravování šablon je velký problém... zatím jsem byl jenom u metody, kdy se vezme statická stránka, v té se udělají úpravy, a programátor ty úpravy dolepí do šablon. Pořád jsem se poohlížel po šablonovacím systému, ke kterému budou nástroje pro designéry.A co to vyřešit jednoduše: Nepsat HTML.
A co to vyřešit jednoduše: Nepsat HTML.Tohle řešení tak úplně nefunguje. Jistě, máme různé wikitexty a podobné... ale ty jsou na články, ne na layout (na který mimochodem ani HTML není žádný zázrak). Navíc někdo musí napsat konvertor... a někdo musí napsat stylopis. No a pokud jde o různé frontpage a composery, tak to nelze seriózně vůbec uvažovat.
Na texty je wysiwyg. Mluvím o layoutu – udělat (polo)klikátko na návrh layoutu a k tomu vygenerovat kostru pro CSS je hračka.Praxe mluví jinak.
Mluvím o tom, že si v CMS naklikáš šířky a uspořádání sloupečků a ono to vygeneruje slušný layout postavený na pár divech a CSS.To jsi neřekl. On ty divy a cssko ale vždycky musí někdo připravit. Já jsem v poslední době spíš viděl takovýten klasický webový cyklus, který začíná grafickým návrhem, ne výběrem z připravených layoutů. Prostě klasické firemní prezentace. Ale i v případě různých hotových CMS musel někdo ty divy předpřipravit, tzn někdo musel to HTML umět a pokud něco nevyhovuje, někdo musí do toho CMS hrábnout a změnit to. Ale pokud se pohybuješ mezi odborníky, kteří často používají slovo "nejde" místo "stálo by to o tisícovku víc", tak to pak jo.
Ten wysiwyg se používá až na vlastní texty, které tam vkládají uživatelé a CMS to jen důkladně pročišťuje.Na toto jsem už odpověděl. Jestli se použije wikitext nebo tlačítkový editor je v podstatě jedno. Wikitext má výhodu přesnějšího ovládání, wysiwyg má výhodu větší myšovitosti.
(a ten je dosti univerzální).Tady bych právě čekal to slabé místo.
PHP a Perl jsou hnusy, ale i v nich se dá napsat dobrý soft.Stejně tak jistí programátoři umí psát Fortran v jakémkoli programovacím jazyce.