<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Python on ilManzo's blog</title><link>https://ilmanzo.github.io/it/tags/python/</link><description>Recent content in Python on ilManzo's blog</description><generator>Hugo</generator><language>it-IT</language><copyright>2012-2026 Andrea Manzini</copyright><lastBuildDate>Thu, 16 Jul 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://ilmanzo.github.io/it/tags/python/index.xml" rel="self" type="application/rss+xml"/><item><title>syscalln't 🚫</title><link>https://ilmanzo.github.io/it/post/teaching-write-to-say-no/</link><pubDate>Thu, 16 Jul 2026 00:00:00 +0000</pubDate><guid>https://ilmanzo.github.io/it/post/teaching-write-to-say-no/</guid><description>Insegnare a write() a dire di no: un&amp;#39;introduzione alle syscall e al fault injection, usando strace per far fallire una syscall a comando</description></item><item><title>Automatizzare la clonazione dei job OpenQA con Python e YAML</title><link>https://ilmanzo.github.io/it/post/automating_job_cloning/</link><pubDate>Wed, 07 Jan 2026 00:00:00 +0000</pubDate><guid>https://ilmanzo.github.io/it/post/automating_job_cloning/</guid><description>&lt;h2 id="-buon-anno-nuovo"&gt;🎉 Buon anno nuovo!&lt;/h2&gt;
&lt;p&gt;Come sa chiunque lavori con &lt;a href="https://open.qa/"&gt;openQA&lt;/a&gt;, si tratta di uno strumento estremamente potente per i test automatizzati. Tuttavia, a volte il flusso di lavoro necessario per riattivare i test a scopo di analisi può sembrare un po&amp;rsquo;&amp;hellip; &lt;em&gt;manuale&lt;/em&gt;.&lt;/p&gt;
&lt;p&gt;Di recente mi sono ritrovato in un ciclo ripetitivo durante il debug di scenari di test complessi. Il mio flusso di lavoro si presentava all&amp;rsquo;incirca così:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Individuare l&amp;rsquo;URL di un job noto come &amp;ldquo;corretto&amp;rdquo;.&lt;/li&gt;
&lt;li&gt;Aprire un editor di appunti veloce.&lt;/li&gt;
&lt;li&gt;Comporre un lungo comando &lt;code&gt;openqa-clone-job&lt;/code&gt; con una marea di parametri di override specifici (&lt;code&gt;BUILD=0&lt;/code&gt;, branch Git personalizzati, esclusione di moduli specifici, ecc.).&lt;/li&gt;
&lt;li&gt;Eseguire il comando nel terminale e attendere l&amp;rsquo;output.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;Scansionare visivamente con fatica l&amp;rsquo;output del terminale&lt;/strong&gt; per individuare gli URL dei nuovi job creati, selezionandoli con il mouse per copiarli.&lt;/li&gt;
&lt;li&gt;Incollarli in &lt;a href="https://github.com/os-autoinst/openqa-mon"&gt;&lt;code&gt;openqa-mon&lt;/code&gt;&lt;/a&gt; o in un file di testo per monitorarne l&amp;rsquo;avanzamento.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Fino a questo momento ho utilizzato uno script &lt;code&gt;Bash&lt;/code&gt; che in un certo senso mi aiutava, ma modificare array giganteschi di argomenti per ogni diverso scenario di debug era noioso e incline all&amp;rsquo;errore.&lt;/p&gt;</description></item><item><title>Testing Headless di Applicazioni GUI PySide/PyQt con pytest-qt</title><link>https://ilmanzo.github.io/it/post/testing_pyside_gui_applications/</link><pubDate>Wed, 22 May 2024 00:00:00 +0000</pubDate><guid>https://ilmanzo.github.io/it/post/testing_pyside_gui_applications/</guid><description>Un approccio al testing headless di programmi GUI</description></item></channel></rss>