There is a company called FatMonkey and they make amazing wall bars that fit into a door frame.

Their magic trick is a slot going from horizontal to vertical, combined with an oval shaped bar. Inserting the bar into the slot locks it in place and prevents it from rotating.

With 12 slots, you can adjust the height of the bar for any exercises you might want. And because the whole thing stands on the floor, it doesn’t put a lot of strain on your door frame, so there is no danger of breaking it.

The downside: at the time of writing, it costs around 300€.

Which I would be happy to pay if I needed an adjustable bar that is easy on the door frame. But I only need one height, and I have an opening in a structural wall with no flimsy frame.

So, I stole borrowed the idea with the slot. Instead of 12 slots, I only made one, and bolted it into the wall.

But first, a CAD model:

I did not want to find out if a 3D print would be strong enough, so I made a template that can be 2D printed.

This template can be transferred to two pieces of plywood and cut out with a band saw or jig saw.

Just glue the parts together:

And bolt on:

I used a 32mm round bar because that was the only one I could find. A bit thicker would probably be better. To get to the oval shape, I filed off a bit at the ends.

Ready for some pull-ups! Or just some hanging.

Suppose the component looks like this:

<script>
  const { count = $bindable() } = props();
</script>

<button onclick={() => count = count + 1}>Click</button>

From another component you would call it like this:

<script>

  let myCounter = $state(0):

</script>

<CountButton bind:count={myCounter}/>

<p>Count is {myCounter}</p>

But from a test:

it('updates the bound counter', async () => {
			let boundCounter = 0;

			const { container } = render(CountButton, {
				props: {
					counter: boundCounter // this is not bound and you can’t use bind:counter here
				}
			});

			const button = container.querySelector('button'):
			button.dispatchEvent(new Event('click'));

		  expect(boundCounter).toBe(1); // nope, still 0
		});

There is a very simple solution to this problem. I could not find it in the docs nor on the Internet. Neither could any AI help me out.

What I ended up doing is checking out the compiled code of the parent component above. If you have installed Svelte plugins in for example VS Code, there is a button in the top right corner to see it.

And this is what bound properties get compiled to:

it('updates the bound counter', async () => {
			let boundCounter = 0;

			const { container } = render(CountButton, {
				props: {
					// simulate bind:count
					get count() {
						return boundCounter;
					},
					set count(value) {
						boundCounter = value;
					}
				}
			});

			const button = container.querySelector('button'):
			button.dispatchEvent(new Event('click'));

		  expect(boundCounter).toBe(1); // works
		});

A getter and a setter! Of course!

And this is how you can test bound properties. And any other “magic” code.

• I could not find any garbage bags that were small enough.
• The too-large, stiffer paper bags were hard to fit in.
• Where I live, you can’t throw those “biodegradable” plastic bags into the organic waste, because they decompose too slowly.
• Those bags are not waterproof, so the bin was always dirty on the inside. I had to clean it all the time, and during that time I didn’t have a bin for my organic waste.

My goal was to get rid of any garbage bags entirely, and to always have a bin available.

The solution: two bins. As soon as one is full, the other one takes over, until the first one is cleaned again.

Alas, I couldn’t find any to buy.

DIY to the rescue.

I had three criteria for my new bins. They had to be:

• dishwasher-safe for easy cleaning
• stackable so as to take up the same space as the old single bin
• 3D printable in one piece

I fired up onshape and got to drawing.

Stackable

The shape is really just a box with rounded corners and a lid on top. To make one bin fit into another, it had to have a narrow bottom and a wider top.

Dishwasher-safe

For the material, I went with PETG instead of PLA (the cheapest, easiest, default 3D printing material), since PLA starts to become flexible at 55-60ºC, and PETG (should) at 80-86ºC - the so-called glass transition temperature.

Well, either I have a particularly powerful dishwasher or I should have calculated with a higher margin:

Switching to ASA (100ºC) solved the problem. ASA is very close to ABS, and that’s what lego bricks are made of, so it is solid.

Printable

My original design featured a band around the top with a horizontal bottom edge - this is not something that can be 3D printed as is, because the edge would have to be floating in the air while being printed.

This meant that quite a substantial support structure was needed to print this - 90g of support material for 320g of material for the actual object.

The solution was to change the edge to a 45 degree angle, which can be printed without any support:

Leakage

One unexpected issue that came up with one of my countless (single digit number of) prototypes was that it was leaking liquids.

In the default settings, walls are printed using a thin infill sandwiched between two layers of solid plastic.

When I changed this to 6 walls, turning the walls into solid plastic, the problem was fixed.

Conclusion

After a few weeks of tinkering and printing, I can now live a slightly happier life, always a waste bin at my disposal, and no more plastic bags (at least for the organic waste).

And so can you - if you have access to a 3D printer. Here are the print files. And the original onshape CAD drawing.

P.S. In a few years, I should have made up for all the printed plastic with the bags I now don’t have to buy anymore. 😬

It turned out that having your hands on a flat surface, i.e. rotated 90° inwards for most of the day is not an ideal position. This causes tension on a bunch of tendons that go from the hand to the — drumroll — elbow. And that constant over-tension then leads to inflammation where the tendons attach to the muscles. And ouch.

The same goes for the hands being parallel to each other, bending the wrists and forcing the rest of your arms into an unnatural position. Here are some pictures.

So, I stopped working from the sofa and got myself a proper screen, (looking down at a laptop screen is also bad for you), a vertical mouse (no more inward rotation) and I started looking into ergonomic keyboards. And this is where it got complicated.

There are a million different kinds of more or less ergonomic keyboards out there. And an equal number of keyfluencers on YouTube telling you that the one sponsoring their video happens to be the best.

 This must have been the first ergonomic keyboard ever sold. PS/2 plug! (via ebay)

My main concern was the inwards rotation of my hands, so I quickly landed on getting a split keyboard (2 separate parts) that I can move around on the desk, and that can be tented. Which is when you tilt the 2 halves of the keyboard outwards so that your hands don’t have to rotate inwards to type on them.

The ZSA Voyager had just come out and it looked to do what I needed. It came with a few tiny studs for a minimal amount of tenting, and with a digital 3D model of the keyboard in order to design and build accessories.

And this is how I got into CAD (computer aided design) and 3D printing. I was going to make my own … tent poles. Or something. Little did I know…

I started off with TinkerCAD. This software is free and easy to learn, but I quickly hit its limits with my somewhat complex shapes and switched to Onshape. This is a professional CAD tool with a free version where all your designs are publicly accessible. Not a problem for me.

While some split keyboards come with little adjustable studs, it quickly became apparent to me that for 3D printing, basically a wedge would be the way to go. 3D printers like to print chunky things, not tiny brittle pieces.

Here is the first version. The far edge follows the shape of they keyboard so it can be placed right under it. Excuse the rough surface.

My next few iterations created a very moderate tilting angle, which I increased with every step. What I quickly realized was that I would also need palm rests that were also tented.

As I experimented with each version, the palm rests got bigger and bigger so that my entire hands would fit on them.

I also had to find a solution to prevent my hands from sliding off of the pads. Notice the left edge curving upwards:

This is the version I have been using for a few months now and it works really well:

And here is the 3d model. Yes, it runs in the browser. After a click you can rotate it around, and if you get an Onshape account you can fork and modify it.

Thankfully my tennis elbow is gone, and I’m hoping to never see it again.

For one, this gives us a goal to work towards (zero issues detected). It also helps to catch regressions or introduce new issues when developing new features.

The kinds of issues I’m talking about are simple things like making sure every <input> tag has a matching label, images have alt attributes etc. Slightly up the ladder are CSS issues like fonts being too small or the contrast between text and background being too weak.

Some of these can be caught with static analysis. Ember JS for example has ember-template-lint which comes with a list of a11y rules.

Because Rails uses erb for templating and generates at least some part of the HTML in Ruby - which is almost inaccessible to static analysis - we can’t just lint our .erb templates.

Try
<%= content_tag(:span, class: 'b') { 'analyzing' } %>
<% 'this'.split('').each do |letter| %><%= letter %><% end %>!

What we need is the HTML that comes out of them. Luckily we have a comprehensive source of rendered HTML: our suite of feature tests using Capybara. All we have to do is capture the HTML that is generated during a test run, write it to the file system and feed that into an a11y checker.

Most people who have used Capybara probably know the save_and_open_page helper, which lives in the Capybara::Session class. Conveniently there is also one called save_page.

The following code hooks into the various Capybara methods that result in HTML output (visit, click_on etc) and stores the HTML in a file.

To avoid generating multiple HTML files per controller/action, the HTML filename consists of the Rails URL with any ids replaced with static placeholders, resulting in only one HTML file per action. The downside here is that we will not capture each erb template in all its states.

We also generate the Rails assets, copy them into the same folder as the HTML files and change the CSS <link>s in the HTML to point to these - this allows us to look at the HTML with working CSS and surface any font size or color contrast issues.

module SaveVisitedPages
  ID_REGEX = /[0-9a-f]{32}/ # change this depending on what id format your app uses

  def visit(*, **)
    super
    save_page_for_url
  end

  def click_link(*, **)
    super
    save_page_for_url
  end

  def click_button(*, **)
    super
    save_page_for_url
  end

  def click_on(*, **)
    super
    save_page_for_url
  end

  def save_page(*, **)
    save_assets
    # change asset path to point to assets in the same directory (see save_assets)
    def self.body
      (driver.html || '').gsub('href="/assets', 'href="./assets').gsub(
        'src="/assets',
        'src="./assets'
      )
    end
    super
  end

  # only save one file per URL so we don't get too many files/duplicate
  # issues for now
  def save_page_for_url
    return unless ENV['SAVE_VISITED_PAGES'] # we set this to true on CI and skip it on dev machines
    return unless current_url && body.present? # i.e. for redirects

    save_assets
    request_method = driver.try(:request)&.request_method || 'NA' # js driver does not support request
    uri = URI.parse(current_url)
    subdomain = uri.hostname.split('.').first

    url_path = uri.path
    url_path.gsub!(ID_REGEX, '1') # replace UUIDs with a constant value so we don't get the same page multiple times

    # change asset path to point to assets in the same directory (see save_assets)
    def self.body
      (driver.html || '').gsub('href="/assets', 'href="./assets').gsub(
        'src="/assets',
        'src="./assets'
      )
    end

    file_path =
      "#{request_method}!!#{subdomain}!!#{url_path.gsub('/', '--').gsub(/[^\w-]+/, '-')[0, 100]}.html"
    save_page(file_path)
  end

  def save_assets
    assets_path = config.save_path.join('assets') # save_path is where the html files go
    rails_assets_path = Rails.public_path.join('assets')
    return if assets_path.exist? # only generate assets if they are missing

    unless rails_assets_path.exist?
      puts('Generating assets for Capybara saved pages...')
      `#{Rails.root.join('bin/rails')} assets:precompile`
    end
    FileUtils.mv(rails_assets_path, config.save_path)
  end
end

Capybara::Session.prepend(SaveVisitedPages)

After including the above code in our test suite and running tests, we get a long list of HTML files in tmp/capybara. We can look at them in a browser and run for example the axe dev tools browser extension.

Or we can run some automated testing: enter pa11y and its sibling (child?) project pa11y-ci. Pa11y lets you run a11y tests from the command line and write the results to various machine and human readable formats.

We use GitHub Actions for CI, so this is what our (simplified) workflow looks like:

.github/workflows/ruby.yml:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: SAVE_VISITED_PAGES=true bundle exec rake test
      - name: Copy Capybara HTML files
        uses: actions/upload-artifact@v4
        with:
          name: capybara-html
          path: tmp/capybara
  pa11y:
    needs:
      - test
    runs-on: ubuntu-20.04 # see https://github.com/pa11y/pa11y-ci/issues/198#issuecomment-1418343240
    steps:
      - uses: actions/checkout@v4
      - name: Download Capybara HTML files
        uses: actions/download-artifact@v4
        with:
          name: capybara-html
          path: tmp/capybara
      - name: Run pa11y
        run: |
          cd pa11y
          yarn
          yarn pa11y-ci ../tmp/capybara/*.html
      - name: Add pa11y report to summary
        if: always()
        run: |
          cd pa11y
          cat ./pa11y-cli-report.md >> $GITHUB_STEP_SUMMARY

We also need to add these files to a pa11y/ folder within the project. These consist of a package.json file so that we can install pa11y from npm, a config file and a custom report that outputs HTML for GitHub.

The last step in the workflow file adds the report to the summary page of the GitHub Actions run:

And that’s it. Automated a11y issue reporting on CI.

Now we just need to start the actual work of getting those 145 errors down to zero. And then we can mark the pa11y job as a required check for merging pull requests.

Some context: at Cobot we run a Rails app that was started in 2009 and has about 1000 .html.erb files, including partials and component views.

I had identified the following issues:

• The syntax is very complex due to the fact that any Ruby construct can be embedded.
  • This makes it harder to read/write views.
  • and also for tools to format them, or do auto-completion, syntax highlighting etc.
• Correctness of HTML (think missing closing tags) cannot be verified by tools.
• I rarely write tests for views (mostly only via feature tests) so confidence in their correctness (also in conjunction with their associated controller) is not very high - I’m also not really planning to get into it.

I like that it’s still HTML (and our designers agree), but I find the Ruby in there problematic. In our frontend Ember JS apps we use Glimmer, which uses the same syntax as Handlebars:

{{#if myCondition}}
  <p>{{firstname}} {{loud lastname}}</p>
{{/if}}

I like the concept of having a limited syntax for control flow and callig into code on top of HTML.

Not too long ago we added glint to our Ember stack, which together with TypeScript gives us static type checking in our Glimmer templates. Very nice.

And that gave me the idea that lead to this post: we already use Sorbet for type checking our Ruby code. If we could have type checking for our Rails views as well, that would give us much more confidence - without having to write tests for them.

So far, I haven’t figured out a way to do this with controllers since the interface between them and views is just too fuzzy. But for view components it was actually easy.

The following code makes a copy of each component’s Ruby class, compiles the associated .erb file to Ruby and embeds it into the class as a method:

require 'pathname'

class ComponentViewCompiler
  INITIALIZE_METHOD_REGEX = /def initialize.*?end/m
  COMPONENTS_PATH = Pathname.new('app/components')

  def initialize(target_dir)
    @target_dir = target_dir
    FileUtils.mkdir_p(@target_dir)
  end

  def compile_components
    COMPONENTS_PATH
      .glob('**/*.html.erb')
      .each do |view_file|
        class_file = view_file.sub_ext('').sub_ext('.rb')
        compile_component(view_file, class_file)
      end
  end

  private

  def compile_component(view_file, class_file)
    view = File.read(view_file)
    compiled_view = compile_view(view)
    code = File.read(class_file)
    call_method =
      "\n\nsig { void }\ndef call\noutput_buffer = ActionView::OutputBuffer.new\n#{
        compiled_view.gsub('@output_buffer', 'output_buffer')
      }\nend\n"
    index = code.match(INITIALIZE_METHOD_REGEX).end(0)
    code.insert(index, call_method) # yes this is ugly. will break with no or multiple initialize methods, e.g. nested classes. but it works.
    target_file =
      @target_dir.join(class_file.relative_path_from(COMPONENTS_PATH))
    FileUtils.mkdir_p(File.dirname(target_file))
    File.write(target_file, code)
  end

  def compile_view(view)
    handler = ActionView::Template.handler_for_extension('erb')
    handler.call(OpenStruct.new(type: 'erb'), view)
  end
end

Given a simple component:

my_component.rb:

# typed: true

class MyComponent < ApplicationComponent
  extend T::Sig # add sorbet

  sig { params(name: String).void } # sorbet method signature
  def initialize(name)
    super
    @name = name
  end

  sig { returns(String) } # sorbet signature
  attr_reader :name
end

my_component.html.erb:

Hello <%= namne %>

This will be compiled to:

compiled_components/my_component.rb:

# typed: true

class MyComponent < ApplicationComponent
  extend T::Sig # add sorbet

  sig { params(name: String).void } # sorbet method signature
  def initialize(name)
    super
    @name = name
  end

  sig { void }
  def call
    output_buffer = ActionView::OutputBuffer.new
    output_buffer.safe_append='hello'.freeze; output_buffer.append=( namne )
    output_buffer
  end

  sig { returns(String) } # sorbet signature
  attr_reader :name
end

The resulting file can be typechecked by sorbet (or steep if you prefer):

$ srb tc

compiled_components/my_component.rb:15: Method namne does not exist on MyComponent https://srb.help/7003
    15 |    output_buffer.safe_append='hello'.freeze; output_buffer.append=( namne )
                                                                             ^^^^^
  Did you mean name? Use -a to autocorrect
    compiled_components/my_component.rb:15: Replace with name
    15 |    output_buffer.safe_append='hello'.freeze; output_buffer.append=( namne )
                                                                             ^^^^^
    compiled_components/my_component.rb:20: Defined here
    20 |  attr_reader :name
          ^^^^^^^^^^^^^^^^^

And as you can see I made a typo in the template.

The downside here is that any type errors point to the compiled class, so nether the filename nor the line number in the error message are correct.

But it’s a start. And to get around the part where this is not working for controllers, we just convert any complex and/or very important view into a component.

As a bonus, I added the component compiler to Procfile.dev, so now as long as bin/rails is running, the compiled components are kept up-to-date automatically.

Procfile.dev:

compiled_component_views: npx -y watch "rails sorbet:compile_component_views" app/components

sorbet.rake:

# typed: false

namespace :sorbet do
  desc 'Generate Ruby code from component views for Sorbet. This allows to type-check component views.'
  task :compile_component_views do
    require 'pathname'
    require 'fileutils'
    require_relative '../component_view_compiler'

    puts 'Compiling component views'
    dir = Pathname.new('compiled_components')
    FileUtils.rm_rf(dir)
    compiler = ComponentViewCompiler.new(dir)
    compiler.compile_components
  end
end

The same Rake task also runs on CI.

Happy static type checking!

Finished the hull! I started by glueing the pre-cut 6mm plywood panels from the kit to the stringers. There were panels for the sides and the bottom. For the round section in-between, I had to cut my own panels. Because of the tight curve, these are only 3mm thick, and I had to apply two layers.

Next up, turning the hull and then working on the inside.

Next up, adding the hull panels.

The kit for my Mini 650 came without any instructions. It took me a whole day to figure out which part goes where. I made a list. Maybe it’ll help somebody else one day.

Not included in the kit:

• stringers
• hardwood cap for the bow
• the plywood covering the tangents
• plywood to cover the hull area between the tangents
• plywood for the inside - berths, water tanks

cabin top

cabin sides - you can see the marks for the windows

cockpit seats/side deck - aft

side deck, foredeck

bottom panels

cockpit sides

hull side - between chine and sheer line

hull side - below chine

cockpit sole

cockpit sole 2

cabin back side

cockpit floor

Setting up the building stocks and bulkheads. The hull is taking shape!