<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Software-Engineering on Oliseus Blog</title><link>https://oliseus.com/tags/software-engineering/</link><description>Recent content in Software-Engineering on Oliseus Blog</description><generator>Hugo -- gohugo.io</generator><language>en</language><managingEditor>simon.bernbeck@gmail.com (Simon Bernbeck)</managingEditor><webMaster>simon.bernbeck@gmail.com (Simon Bernbeck)</webMaster><copyright>© 2024 Simon Bernbeck. All rights reserved.</copyright><lastBuildDate>Mon, 05 Oct 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://oliseus.com/tags/software-engineering/index.xml" rel="self" type="application/rss+xml"/><item><title>Doseframe: Making Perfusor Calculations Easier to Check</title><link>https://oliseus.com/digital-odyssey/posts/doseframe-introduction/</link><pubDate>Mon, 05 Oct 2026 00:00:00 +0000</pubDate><author>simon.bernbeck@gmail.com (Simon Bernbeck)</author><guid>https://oliseus.com/digital-odyssey/posts/doseframe-introduction/</guid><description>&lt;p>A syringe pump delivers medication continuously. Preparing one can involve a prescription, a stock solution, a dilution, a final concentration and a pump rate. Each value has a unit. A calculation may be short on paper, yet the handover between prescribing, preparing and setting the pump gives mistakes several places to enter.&lt;/p>
&lt;p>Doseframe is a project I am developing during my computer science master&amp;rsquo;s studies. The idea came from conversations with physicians in neonatal care about perfusor preparation and the work around it. Their feedback has changed the design: the handover of a spoken prescription matters, clinicians need to see the entered dose clearly, and the staff who prepare syringes must still test whether the proposed workflow fits their practice. The project is currently a design and prototype, not a clinical calculator ready for patient care.&lt;/p></description><media:content xmlns:media="http://search.yahoo.com/mrss/" url="https://oliseus.com/digital-odyssey/posts/doseframe-introduction/featured.svg"/></item><item><title>PrivDev: What a Code Scanner Can Tell Us About Privacy</title><link>https://oliseus.com/digital-odyssey/posts/privdev-privacy-research-introduction/</link><pubDate>Mon, 05 Oct 2026 00:00:00 +0000</pubDate><author>simon.bernbeck@gmail.com (Simon Bernbeck)</author><guid>https://oliseus.com/digital-odyssey/posts/privdev-privacy-research-introduction/</guid><description>&lt;p>A developer can search a codebase for personal data and still miss the question that matters: what should the team do with the finding? A scanner may report an email address or a storage pattern. It cannot see the full purpose of processing, the people involved, every technical safeguard, or the organisation&amp;rsquo;s legal decisions. PrivDev began with that gap between a technical observation and a responsible privacy review.&lt;/p>
&lt;p>PrivDev is my research project at PUC-Rio&amp;rsquo;s AISE Laboratory. Its working idea is a &lt;strong>security-to-privacy bridge&lt;/strong>: preserve what a scanner actually observed, connect it to a shared vocabulary, and make the reasoning available for inspection. I want developers to receive a useful starting point while leaving decisions that require context with the people who have it.&lt;/p></description><media:content xmlns:media="http://search.yahoo.com/mrss/" url="https://oliseus.com/digital-odyssey/posts/privdev-privacy-research-introduction/featured.svg"/></item><item><title>PrivDev: Turning Static-Analysis Findings into Privacy Knowledge</title><link>https://oliseus.com/digital-odyssey/posts/privdev-static-analysis-to-privacy/</link><pubDate>Wed, 29 Jul 2026 00:00:00 +0000</pubDate><author>simon.bernbeck@gmail.com (Simon Bernbeck)</author><guid>https://oliseus.com/digital-odyssey/posts/privdev-static-analysis-to-privacy/</guid><description>&lt;p>The first PrivDev study connects data-type labels from a code scanner to a privacy vocabulary. That sounds straightforward until a label is ambiguous, the vocabulary has no close match, or a graph asserts more than the scanner could know. This article records what the first implementation accomplished and what later review changed. For the wider research programme, see the &lt;a
href="../privdev-privacy-research-introduction/">PrivDev introduction&lt;/a>.&lt;/p>
&lt;h2 class="relative group">From a scanner label to a category
&lt;div id="from-a-scanner-label-to-a-category" class="anchor">&lt;/div>
&lt;span
class="absolute top-0 w-6 transition-opacity opacity-0 ltr:-left-6 rtl:-right-6 not-prose group-hover:opacity-100">
&lt;a class="group-hover:text-primary-300 dark:group-hover:text-neutral-700 !no-underline" href="#from-a-scanner-label-to-a-category" aria-label="Anchor">#&lt;/a>
&lt;/span>
&lt;/h2>
&lt;p>Bearer CLI provides the 122 input data-type labels used in this study. The pipeline relates them to personal-data categories in the &lt;a
href="https://www.w3.org/community/reports/dpvcg/CG-FINAL-pd-20240801/"
target="_blank"
>Data Privacy Vocabulary&amp;rsquo;s PD extension&lt;/a>. The output is an RDF/Turtle graph that can be queried with SPARQL. It records a proposed interpretation of each scanner label, not a description of every real processing activity in which that label might occur.&lt;/p></description></item></channel></rss>