Šestice firem označovaných jako „MAMAAN“ – tedy Meta (Facebook, Instagram), Alphabet (Google), Microsoft, Apple, Amazon a Netflix – je zodpovědná za více než padesát procent světového internetového provozu. Dalšími velkými hráči jsou TikTok a Disney+. Společně tak zásadně určují podobu digitálního prostředí, spotřebitelského chování i budoucích trendů v oblasti technologií. I přesto, že se podíl těchto gigantů od roku 2023 o něco snížil, jejich dominantní postavení zvyšuje volání po regulaci.
Evropská komise (EK) navrhuje zavést plošný poplatek ve výši dvou eur (zhruba 50 Kč) za každý malý balík vstupující do Evropské unie. Poplatek se má týkat balíků v hodnotě do 150 eur (zhruba 3700 Kč), které v EU nepodléhají clu. V loňském roce bylo do EU doručeno kolem 4,6 miliardy takovýchto balíků. Poplatek má krýt náklady na kontroly rostoucího počtu zásilek levného zboží, které pochází především z Číny.
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."
Článek přináší doporučení (včetně kompletního kompilovatelného příkladu), jak navrhnout antovské skripty v případě složitějších projektů obsahujících více výsledných produktů provozovaných v různých konfiguracích, na kterých pracuje více vývojářů.
Už se vám stalo, že jste si stáhli zdrojovou verzi nějakého populárního open-source produktu v Javě a po hodině marných pokusů o kompilaci jste to nakonec vzdali? Klíčem k tomu, abyste jako autoři ušetřili svým uživatelům podobné rozčarování, je návrh robustního build systému.
Motivací k napsání tohoto článku je autorova zkušenost, že se nevyplácí šetřit čas na vytvoření kvalitního build systému. Tím spíše, pokud je součástí buildu také instalace zahrnující potenciálně nebezpečné operace, jako třeba vymazání databázových tabulek. Myslete na to, že kompilovat projekt mohou kromě vás také jiní programátoři nebo správci systému. Ušetřený čas na ledabyle odvedeném návrhu se vždy i s úroky zaplatí v pozdější fázi projektu. A to zrovna když se vám to bude nejméně hodit - když se něco stane nezvladatelným a je nutné provést refactoring (což v případě, že nejste autorem, může být krajně nevděčná práce).
Obvykle výsledný produkt projektu obsahuje různé konfigurační soubory, moduly či data, které společně tvoří uníkátní konfiguraci. Záleží to na typu projektu a zvolené architektuře, ale nejčastěji to bude databázový driver, URL databázového připojení a nastavení úrovně logování. Pokud vytváříte k serverové aplikaci síťového GUI klienta (nejlépe s využitím JNLP a Java Web Start technologie), který komunikuje s aplikačním serverem, potřebuje klient znát IP adresu a nastavení poskytovatele adresářových služeb JNDI, se kterým se připojí ke komponentám nebo frontám aplikačního serveru.
Díky dynamické povaze Javy mohou být dnešní systémy za běhu vysoce parametrizovatelné. Všechno je "pluggable" a "customizable". Pokud jste někdy procházeli konfiguračními XML soubory aplikačního serveru JBoss nebo XML soubory s deskriptory J2EE aplikace, tak víte, co to je za monstra. Nic proti tomu. Špatné však je, když je tím zbytečně zatěžován koncový uživatel, byť by to byl programátor.
Technologie Java Web Start umožňuje pouhým otevřením odkazu v HTML stránce nainstalovat a bezpečně spustit plnohodnotnou desktopovou aplikaci. (Stáhne potřebné knihovny na disk a se svolením uživatele vytvoří na ploše a v nabídce programů zástupce pro spuštění. Při dalším spouštění pak ověřuje, zda na webu není novější verze a pokud ano, tak ji automaticky aktualizuje a spustí. To vše bez zásahu uživatele.) Pokud chceme s pomocí této technologie vytvořit naprosto bezúdržbovou aplikaci, musí být veškerá nastavení přibalena k jar souborům aplikace během buildu.
Cíl je tedy jasný: pokud se rozhodnu vydat novou verzi, tak jediné, co si
přeji udělat, je na své vývojářské stanici spustit z příkazového
řádku povel ant deploy
. Nic víc. Tečka. Žádné ruční balení,
kopírování, žadná editace konfiguračních souborů, žádné opětovné
konfigurování reinstalovaných produktů před či po spuštění.
Ant přímo vybízí k vytvoření alespoň minimální dokumentace k buildu, která má pro toho, kdo si projekt stáhne a bude kompilovat, naprosto zásadní význam. Dokumentace k build skriptu se zobrazí pomocí povelu:
ant -projecthelp
|
Výsledkem může být např. tento jednoduchý výstup:
Buildfile: build.xml
|
Vytvoření výše uvedené dokumentace je velmi snadné. Prvních pár řádků
s obecnou informací o projektu se vytvoří ve skriptu pomocí XML značky
description
umístěné na počátku pod kořenovou značkou
project
:
<project name="AbcKlient" default="package" basedir=".">
|
V seznamu cílů se popis cíle vyskytne tehdy, obsahuje-li značka
target
příslušného cíle atribut description
:
<target name="deploy" |
Open source projekty používající Ant konvergovaly časem k určité formě strukturování a pojmenování cílů (targets) ve skriptech. Pokud můžete, držte se těchto osvědčených konvencí. Všichni, kdo budou váš skript spouštět, vám budou vděčni, když se bude skript chovat tak, jak jsou zvyklí.
K standardním cílům by měl patřit cíl package
, který
vytvoří hotový zabalený produkt obsahující veškeré knihovny,
spouštěcí skripty apod. Pro testování je ideální, pokud je takto
zabalený produkt bez další instalace přímo spustitelný.
Jiným často používaným cílem bude cíl deploy
, který
provádí instalaci produktu, ať již na aplikační server v případě J2EE
aplikace nebo web server v případě JNLP klienta.
Hlavní zásada zní: adresář src
obsahující zdrojové
kódy je nedotknutelný. Soubory vyžadující konkrétní nastavení
(IP adresy, URL a různé další konstanty) by měly být vytvořeny
ve formě šablon obsahujících proměnné, které se teprve v průběhu buildu
nahradí konkrétními hodnotami.
Podobně jako zdrojové kódy by měl být nedotknutelný také build skript.
Ant umožňuje nastavovat hodnoty proměnných několika způsoby.
Buď je to značkou <property name="..." value="...">
nebo textovým souborem s obsahem definovaných hodnot pomocí značky
<property file="..." />
. Přesuňte do textových
souborů právě ty hodnoty, které očekáváte, že uživatel může měnit,
a okomentujte jejich význam. Používáte-li např. jiný typ kompilátoru
než je obvyklé (třeba jikes), přesuňte typ kompilátoru jako
parametr do externího souboru. Zkrátka, ve skriptu nemají co dělat
nastavení závislá na vašem systému.
Pro konkrétní nastavení je dobré vytvořit v projektovém adresáři
podadresář conf
, který bude obsahovat konfigurační
profily s hodnotami nastavení pro jednotlivá cílová prostředí.
Jednotlivé konfigurační profily se pak přepínají pomocí jediného
řádku v souboru build.properties
v hlavním adresáři
projektu. Podrobně si tuto techniku vysvětlíme v další části
článku.
Ačkoliv lze více podprojektů organizovat pomocí jediné hierarchie adresářů zdrojových kódů tříd a jediným sdíleným adresářem společných knihoven, nelze tento postup pro komplexnější projekty doporučit. Brzy totiž ztratíte přehled, které knihovny potřebuje ten který podprojekt a údržba build skriptu se záhy stane noční můrou.
Z dlouhodobého hlediska je výhodnější, když má každý podprojekt svůj adresář knihoven, zdrojových kódů a svůj vlastní build skript. Zkrátka, je co nejvíc izolován od zbytku projektu. Jistou nevýhodou může být skutečnost, že některé společné knihovny jsou na více místech v projektovém adresáři, ale v praxi je tato nevýhoda spíše zanedbatelná.
Pokud má každý podprojekt svůj build skript, je žádoucí vytvořit hlavní build skript, který zajistí hromadné vykonání skriptů jednotlivých podprojektů.
V ideálním případě je izolace projektu dotažena až tak daleko, že projekt obsahuje vlastní kopii Antu. Jelikož se Ant neustále vyvíjí, nenastane situace, že projekt vyžaduje jinou verzi Antu, než máte v systému.
V dnešní části jsme si vysvětlili zásady, které je dobré dodržovat pro robustní návrh build systému. V další části článku se podíváme na reálný příklad build skriptů, které ilustrují, jak tyto zásady použít.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej: