<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Hugo Baldwin</title>
    <description>The latest articles on DEV Community by Hugo Baldwin (@byzantime).</description>
    <link>https://dev.to/byzantime</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3808764%2F0a56e7e5-d77f-4ffa-b563-9143e8696a37.jpeg</url>
      <title>DEV Community: Hugo Baldwin</title>
      <link>https://dev.to/byzantime</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/byzantime"/>
    <language>en</language>
    <item>
      <title>Hosaka Studio v0.1.147: Introducing the Layout Track</title>
      <dc:creator>Hugo Baldwin</dc:creator>
      <pubDate>Fri, 27 Mar 2026 07:54:49 +0000</pubDate>
      <link>https://dev.to/byzantime/hosaka-studio-v01147-introducing-the-layout-track-1f78</link>
      <guid>https://dev.to/byzantime/hosaka-studio-v01147-introducing-the-layout-track-1f78</guid>
      <description>&lt;p&gt;What is a "layout", you might be wondering? I'm glad you asked!&lt;/p&gt;

&lt;p&gt;When you record your screen you typically get your desktop captured as video - and that's it.  Hosaka Studio is a little different: it simultaneously captures your screen, webcam, microphone input, system audio, and cursor movements.  This means that at recording time, you don't have to make any decisions about presentation. You just capture everything, and shape it later.&lt;/p&gt;

&lt;p&gt;That shaping is where the fun begins.&lt;/p&gt;

&lt;p&gt;Screen recordings by themselves aren't always particularly attention-grabbing, and the creator tends to have limited means available to direct the viewer's attention.  Hosaka's editor already had two tools for this.  The &lt;strong&gt;clip track&lt;/strong&gt; lets you adjust where the recording starts and ends, cut out bloopers, or change the pace of individual segments.  The &lt;strong&gt;zoom track&lt;/strong&gt; lets you insert zoom effects that pull the viewer's eye toward what matters.&lt;/p&gt;

&lt;p&gt;As of v0.1.147, there's a third: the &lt;strong&gt;layout track&lt;/strong&gt;.&lt;/p&gt;

&lt;h2&gt;
  
  
  What the layout track does
&lt;/h2&gt;

&lt;p&gt;A layout describes the video feeds that are displayed at any given moment, and how they're arranged. By default, a recording shows your screen with your webcam inset picture-in-picture style in one corner - safe and predictable. But sometimes you want to address your audience directly without the distraction of your screen behind you. For that, you need the webcam full-screen.&lt;/p&gt;

&lt;p&gt;The layout track makes transitions between these arrangements a first-class concept in the timeline.  You place a layout change at any point, and Hosaka handles the transition.  Webcam in the corner for the technical walkthrough, full-screen face cam when you explain the bigger picture - and a smooth switch between them without touching a video editor.&lt;/p&gt;

&lt;p&gt;It's a small addition on the surface but underneath reflects the Hosaka philosophy: the moment of capture and the moment of presentation are separate problems, and giving creators control over both is the whole point.&lt;/p&gt;




&lt;p&gt;If you're a Linux user who's felt the gap between what Mac creators get out of the box and what's been available on your platform, Hosaka Studio was built for you. It's available now at &lt;a href="https://hosaka.studio" rel="noopener noreferrer"&gt;hosaka.studio&lt;/a&gt;, with a free trial and no account required.&lt;/p&gt;




&lt;p&gt;Hosaka Studio is a labour of love for me.  I believe Linux users both deserve and appreciate visual polish, intuitive UI and solutions that "just work".  If you've got questions, hit me up in the comments!  I'm more than happy to answer.&lt;/p&gt;

</description>
      <category>linux</category>
      <category>archlinux</category>
      <category>debian</category>
      <category>ubuntu</category>
    </item>
    <item>
      <title>Measure, Benchmark, Ship: Building Better Software with AI</title>
      <dc:creator>Hugo Baldwin</dc:creator>
      <pubDate>Mon, 23 Mar 2026 03:03:49 +0000</pubDate>
      <link>https://dev.to/byzantime/measure-benchmark-ship-building-better-software-with-ai-2anf</link>
      <guid>https://dev.to/byzantime/measure-benchmark-ship-building-better-software-with-ai-2anf</guid>
      <description>&lt;h2&gt;
  
  
  1) You can't improve what you can't see
&lt;/h2&gt;

&lt;p&gt;The saying famously goes, "what gets measured gets managed".  Or, "the nail that sticks out, gets hammered".  Therefore to manage something you must first measure it; to hammer the nail, you must be able to detect it sticking out.  It's imperative to identify specific metrics you care about and track them.  For Hosaka Studio the big ones are:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Time to first paint when opening the app for the first time;&lt;/li&gt;
&lt;li&gt;Time spent capturing each frame (screen and webcam) in milliseconds;&lt;/li&gt;
&lt;li&gt;Time to first paint when opening the recording editor;&lt;/li&gt;
&lt;li&gt;Editor preview playback performance, measured in frames per second and milliseconds spent processing each frame.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;These metrics are crucial to ensuring the app captures everything at native framerate AND responds instantly to user input.  All of these metrics are calculated and logged in debug mode (some are only sampled every 5s).  There's also terminal colouring that changes the numbers to red to grab my attention should there be a regression in any of the metrics.&lt;/p&gt;

&lt;h2&gt;
  
  
  2) Unit tests cost nothing yet are worth everything
&lt;/h2&gt;

&lt;p&gt;AI has greatly reduced the cost of writing software, and that includes unit tests - so have them written!  Although Claude Code runs tests without explicit prompting, I have a simple two line instruction in my project CLAUDE.md files instructing Claude how to run unit tests:&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight shell"&gt;&lt;code&gt;&lt;span class="c"&gt;# Run tests&lt;/span&gt;
uv run pytest

&lt;span class="c"&gt;# Run the smoke test suite&lt;/span&gt;
uv run pytest &lt;span class="nt"&gt;-m&lt;/span&gt; smoke &lt;span class="nt"&gt;-v&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;After any new feature is implemented if there aren't unit tests included as part of that feature, have them written: "Ensure there's unit test coverage for any new or untested behaviour implemented".&lt;/p&gt;

&lt;h2&gt;
  
  
  3) Let AI do the donkey work (smoke testing)
&lt;/h2&gt;

&lt;p&gt;After making codebase changes it's imperative the code is linted, tested and also manually tested.  However manually testing your app only for it to immediately fail with an exception is both time-consuming and frustrating.  Ensure that AI can exercise as many features of your app via the CLI (or other means) as possible - even if &lt;strong&gt;that means adding a CLI or batch mode to your app&lt;/strong&gt;.  This allows AI to smoke-test functionality and allows it to find and identify fixes before handover.&lt;/p&gt;

&lt;p&gt;For &lt;a href="https://hosaka.studio" rel="noopener noreferrer"&gt;Hosaka Studio&lt;/a&gt;, that meant adding a CLI mode that allows humans and AI to use it non-interactively, e.g.: &lt;code&gt;hosaka --auto --duration 60 --export&lt;/code&gt; will create a 60-second recording and export it to the default location (on Linux, your &lt;code&gt;~/Videos&lt;/code&gt; directory).  This also provides a bulletproof, un-fudgeable way to ensure the recording pipeline works end-to-end.&lt;/p&gt;

&lt;p&gt;Monitoring CI jobs, analysing failures and creating fixes can all be done automatically.  If you're using GitHub, install and authenticate the &lt;code&gt;gh&lt;/code&gt; tool.  There's a corresponding tool available for GitLab also.  Now your agent can check CI jobs, analyse failures and create fixes - whether that's directly ("Find out why this job failed and create a fix: &lt;code&gt;&amp;lt;URL&amp;gt;&lt;/code&gt;") or monitoring ("Monitor this job, create and push fixes as appropriate until it runs green &lt;code&gt;&amp;lt;URL&amp;gt;&lt;/code&gt;").&lt;/p&gt;

&lt;h2&gt;
  
  
  4) Unleash the 1-3 punch combo
&lt;/h2&gt;

&lt;p&gt;Numbers one and three can be combined in a powerful way to smash performance metrics.  Tell the AI to identify specific improvements that would improve &lt;code&gt;&amp;lt;specific metric&amp;gt;&lt;/code&gt;, benchmark them, then present its findings to you in the form of a plan.  Now you've given AI visibility into the numbers you care about AND the agency to experiment and benchmark performance against your metrics.&lt;/p&gt;

&lt;p&gt;As a direct result of this technique Hosaka Studio moved from its initial proof-of-concept &lt;code&gt;Pillow&lt;/code&gt; reliance to &lt;code&gt;Pillow-SIMD&lt;/code&gt; (faster than OpenCV but still CPU-bound).  Then from &lt;code&gt;Pillow-SIMD&lt;/code&gt; to GPU composition.  Now even the GPU composition continues to be optimised further to improve performance.  As a result I'm happy to say that Hosaka Studio excels at screen recording on both high-end machines and decade-old netbooks.&lt;/p&gt;

&lt;h2&gt;
  
  
  Final notes
&lt;/h2&gt;

&lt;p&gt;None of this should be taken as implying you should ignore standard software development best practices.  In fact, all of these suggestions can only exist &lt;em&gt;within&lt;/em&gt; a robust framework designed to function as a ratchet mechanism for code quality.  Others have already noted that the industries best-placed to take advantage of AI are ironically those which are heavily-regulated, because they already have robust, often legally-required QA processes.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Garbage in, garbage out&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;If you have children you will (hopefully) have realised that saying "Don't touch" / "Don't kick your brother" / "Don't draw on the walls" is a waste of time.  In LLM-parlance, you are giving them useless context and their response will likely continue to revolve around your (unhelpful) input.  It's better instead to move things forward to something constructive, toward your desired end state, whatever that may be - "Play with &lt;code&gt;&amp;lt;object&amp;gt;&lt;/code&gt;", "Come and help me with &lt;code&gt;&amp;lt;something&amp;gt;&lt;/code&gt;", "Stroke the cat gently" etc.  Deal with your frustration privately if possible - you're (supposed to be) the adult here.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;To err is human, to forgive Divine&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;If erring is human, machines made by human hands are capable of even greater error.  They'll err &lt;em&gt;at least as much, if not more&lt;/em&gt;.  So take everything AI says or does with a pinch of salt.  Often, though not always, it's only as good as the sum of its parts - the training data.  It says something is impossible?  Don't believe it.  Tell it:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;to research online then get back to you;&lt;/li&gt;
&lt;li&gt;X,Y &amp;amp; Z all managed to implement &lt;code&gt;&amp;lt;foo&amp;gt;&lt;/code&gt; so it's absolutely possible;&lt;/li&gt;
&lt;li&gt;this is a commercial product for paying users, &lt;code&gt;&amp;lt;xyz&amp;gt;&lt;/code&gt; is unacceptable&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;The last one is because LLMs are trained heavily on FOSS and its conventions, some of which are unhelpful.  For example, making users jump through hoops in order to use software!  I believe software should make your life easier - I take great pride in my work and the software I create must reflect that.&lt;/p&gt;

</description>
      <category>softwareengineering</category>
      <category>productivity</category>
      <category>screenrecording</category>
      <category>linux</category>
    </item>
  </channel>
</rss>
