Specialisté společnosti ESET zaznamenali útočnou kampaň, která cílí na uživatele a uživatelky v Česku a na Slovensku. Útočníci po telefonu zmanipulují oběť ke stažení falešné aplikace údajně od České národní banky (ČNB) nebo Národní banky Slovenska (NBS), přiložení platební karty k telefonu a zadání PINu. Malware poté v reálném čase přenese data z karty útočníkovi, který je bezkontaktně zneužije u bankomatu nebo na platebním terminálu.
V Ubuntu 25.10 byl balíček základních nástrojů gnu-coreutils nahrazen balíčkem rust-coreutils se základními nástroji přepsanými do Rustu. Ukázalo se, že nový "date" znefunkčnil automatickou aktualizaci. Pro obnovu je nutno balíček rust-coreutils manuálně aktualizovat.
VST 3 je nově pod licencí MIT. S verzí 3.8.0 proběhlo přelicencování zdrojových kódů z licencí "Proprietary Steinberg VST3 License" a "General Public License (GPL) Version 3". VST (Virtual Studio Technology, Wikipedie) je softwarové rozhraní pro komunikaci mezi hostitelským programem a zásuvnými moduly (pluginy), kde tyto moduly slouží ke generování a úpravě digitálního audio signálu.
Open source 3D herní a simulační engine Open 3D Engine (O3DE) byl vydán v nové verzi 25.10. Podrobný přehled novinek v poznámkách k vydání.
V Londýně probíhá dvoudenní Ubuntu Summit 25.10. Na programu je řada zajímavých přednášek. Zhlédnout je lze také na YouTube (23. 10. a 24. 10.).
Gemini CLI umožňuje používání AI Gemini přímo v terminálu. Vydána byla verze 0.10.0.
Konference OpenAlt 2025 proběhne již příští víkend 1. a 2. listopadu v Brně. Nabídne přibližně 80 přednášek a workshopů rozdělených do 7 tematických tracků. Program se může ještě mírně měnit až do samotné konference, a to s ohledem na opožděné úpravy abstraktů i případné podzimní virózy. Díky partnerům je vstup na konferenci zdarma. Registrace není nutná. Vyplnění formuláře však pomůže s lepším plánováním dalších ročníků konference.
Samsung představil headset Galaxy XR se 4K Micro-OLED displeji, procesorem Snapdragon XR2+ Gen 2, 16 GB RAM, 256 GB úložištěm, operačním systémem Android XR a Gemini AI.
Před konferencí Next.js Conf 2025 bylo oznámeno vydání nové verze 16 open source frameworku Next.js (Wikipedie) pro psaní webových aplikací v Reactu. Přehled novinek v příspěvku na blogu.
Sovereign Tech Fund oznámil finanční podporu následujících open source projektů: Scala, SDCC, Let's Encrypt, Servo, chatmail, Drupal, Fedify, openprinting, PHP, Apache Arrow, OpenSSL, R Project, Open Web Docs, conda, systemd a phpseclib.
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...
Jenže to ještě nějaký čas potrvá, tak je potřeba se uchýlit k něčemu méně dokonalému :)
Své webové aplikace píši v Perlu5, ten mi do ruky padne nejlépe. Uznávám ale, že to není zrovna skvělá volba pro někoho, kdo chce spolupracovat s více lidmi, kteří nejsou zase tak zkušení programátoři (málokdo v Perlu programuje hezky za méně než rok praxe).
Python a Ruby mi přijdou jako daleko lepší volby než Java z toho prostého důvodu, že si nehrají na to, že jsou celým vesmírem, vně kterého nic neexistuje. Například když seženu novou krásnou knihovnu a chtěl bych ji použít, napsat na ni bindingy pro Python je velmi snadné. U Javy mi to nikterak snadné nepřijde.
Podle mě jazyk jako každý jiný, jen má docela velkou tradici v jistém specifickém okruhu programátorů/adminů. Setrvačnost, zejména tu bych za tím viděl.
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.
Základní ochranou proti SQL injekcím jsou parametrizované/připravené dotazy – vždyť to umí i PHP. Dotaz se pak „nelepí“ z kousků textu, ale dají se do něj otazníky (nebo pojmenované parametry – např. :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
(A stejně jako u SQL, namísto slepování toho kódu se mají vstupy od uživatele předat v samostatném poli, tuším se mu říká "scope".)
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.
. Právě "raw sql" jsem se chtěl primárně vyhnout.
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.
ale v čem jiném bys to (#110) chtěl napsat, aby to bylo kratší nebo srozumitelnější?
</flame>
+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
U vetsich bych si prvne dal (pokud mozno peclive
) dohromady, co vsehcno by to melo umet, co bude potreba a vybiral podle toho... (se mi kdysi stalo, ze jsem bezhlave vybral Groovy, ze se neco noveho naucim, a ve chvili, kdy jsem zjistil, ze tam neni podpora XML-RPC pres HTTPS (nebo neco podobneho, nejsu si uz uplne jisty), tak jsem musel resit, jestli to prepisovat do Javy nebo si to tam sam dodelat ... takze misto efektivniho vyvoje jsem venoval relativne dost casu reseni tohoto problemu a nadavani si, jaky su dement)
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…"
Já bych si vybral podle zadání. Když to bude nějaká bankovni megaaplikace, kde na každý řádek kódu připadá stránka analýzy, tak Javu. Když půjde by šlo prevážně o práci s textem, tak perl. Když by to mělo být hodně flexibinlí, tak Ruby nebo Python. Jednoduché věci je nejrychlejší zbastlit v php. A na extrémní výkon samozřejmě C, ale to bych asi šel cestou prototypování v pythonu a následného přepisu jen toho nejdůležitějšího do C.
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.