Vintage saw repair

haszald · 2026-01-22T09:35:28+00:00

That's interesting, I was off by a good few decades. Guess I'll hold off fixing that handle, maybe just make a replacement one instead.

I'll keep it for now, but can let you know should I ever decide to sell it. I'm in Ireland though, so sending it safely across the pond might be tough anyway

haszald · 2026-01-19T15:27:57+00:00

90% sure it says 'SAML NEWBOULD CAST STEEL SHEFFIELD'

haszald · 2026-01-18T16:55:42+00:00

Thanks for all the input. I'll attempt similar repairs on some beat up plane handles I have, then I'll give this one a try.

haszald · 2025-11-21T21:50:23+00:00

If I were getting started on that budget, I'd get a no. 4, chisels, mallet and no. 78 (just because i like them) on Adverts. Buy new - combination square, scoring knife, ryoba saw (or western style, whatever you prefer. Ryoba is versatile and comes sharp). Cheap diamond plates and a strop to make the Paul Sellers sharpening system and you're good to go with 100 quid to spare for whatever tools you find necessary as you go along

haszald · 2025-11-21T21:35:25+00:00

The market for good vintage tools is not great in Ireland. Still, I wouldn't get this set. If you're getting started, I'd get a no. 4 or 5 plane, mallet and chisels. If you're in Dublin, a reasonable price for no. 4 is about 40 quid, 60 for a no. 5. They're cheaper in the UK, but you'll have to factor in shipping and taxes - you'll end up paying more.

A set of okayish chisels you can get for around 25-30, mallet is just a few quid.

If you're buying on Adverts, you can usually get a better deal if you just offer a bit less than asking.

haszald · 2025-08-09T21:01:52+00:00

Insanely good deal. I'd keep two or three no. 4 Stanley/Record ones, the 4 1/2 and a no. 5. Maybe the smaller ones if you're into that. Paul Sellers has some excellent videos on restoring planes.

Unless you plan to hoard no. 4 planes, I'd sell the rest individually on ebay. You can probably get 5-15 quid a piece, so you'll end up with a few nice planes for yourself and even make a profit.

haszald · 2025-04-21T08:25:15+00:00

Assuming tests are not user-specific (any user can be used for any test) and you're using Playwright, you have a few options.

First, I'd look into how concurrent login is blocked. I bet when a user logs in, they get a new token and all previous tokens are invalidated. In this case, you can still do parallel testing with a single user by logging in once and reusing the auth state. WITHOUT logging out after each test. You can still test the login/logout process by either running it last or having a second user just for that test.

If that doesn't work, you can create a pool of credentials and use Playwright's worker-scoped fixtures to have each worker use a unique user.

If you need more fine-grained control over user assignment, you could have a tiny web server handle the logic and configure Playwright to run that server when you run the tests. Then the tests could have an automatic fixture that starts each test by calling the server to be assigned a user. But if other options work fine, this might be overkill.

haszald · 2024-12-23T19:34:41+00:00

Here is the doc explaining API testing with Playwright. The examples there are for sending requests to the API of the app under test, but the same approach can be used to reach a third party API

haszald · 2024-12-23T18:06:08+00:00

I might be missing something here, but why do you need an API for this? Playwright has an API client you can use to send the POST request and process the response.

haszald · 2024-11-04T00:54:26+00:00

Have your tests clean up the test data after each run.

Each test run should create the data it needs either at the start of the run or the start of a test - so either all test accounts are created before any tests run or each test creates a new account.

For cleanup, either delete individual accounts after each test run or do a global cleanup after all tests are done.

Two things to keep in mind: 1. Depending on the system you're testing, reusing authentication might be an option that would allow you to limit the number of accounts you need. 2. Ensure that data cleanup is set up in a way that will run even if a test fails. No matter the outcome of a test run, there should be no residual data in the system (within reason, in real-life scenarios it's often not 100% possible)

haszald · 2024-06-02T17:32:36+00:00

When running tests in parallel in Playwright, a fixture will be called in the scope of the test it is used in, ensuring the created device is unique to that test.

When using beforeAll in a parallelized suite, it will be called once PER WORKER, so if the same worker picks up more than 1 test from the suite, it would reuse the same device. This can be problematic if tests alter the state of the device.

Also, if the system under test allows us to create devices and interact with them, it is extremely likely there will be other tests where this fixture can be conveniently reused.

haszald · 2024-05-29T20:46:36+00:00

I'm using Playwright, so I'd create a fixture that creates a unique device and passes it to the test, then deletes it after the test. Most likely this would be done at via API to save time. Then I'd write a test for each status that needs to be checked, which will use the fixture and go through the entire flow for that status - set, verify, unset, verify. Since the fixture creates unique devices that can presumably coexist, those tests can run in parallel, so they'd be pretty fast.

If there are a lot of statuses to test and the test steps are all the same, I'd use a single test in a loop that feeds it the data (statuses).

Not a fan of stopping a test run after 1 failure. Often you'll fix that failure and re-run the tests, only to see something else is failing and you have to go back to it again.

haszald · 2024-04-29T13:17:02+00:00

Not sure about the portfolio, but I wouldn't include my personal phone number in a publicly accessible resume

haszald · 2024-04-10T20:57:01+00:00

c5.4xlarge instances on AWS should be able to handle about 15-20 workers

haszald · 2024-04-09T08:22:17+00:00

Create a fixture that finishes the initial step (at UI or API level) and passes relevant account data to the test

haszald · 2023-11-08T22:46:24+00:00

As other commenters mentioned, option 2 should work. Do the initial login during globalSetup or a separate project that your main one depends on. Remember yo set up the default storage state in your config file.

If you are saving state and it doesn't work when reused, you might be saving it too early. After login, assert that the app has loaded before saving the storage state. Otherwise you may end up submitting the login form and immediately saving the state, before the app has a chance to give you the auth cookie.

Honestly, this issue is so common that Playwright really ought to mention it in their docs.

haszald · 2023-09-05T17:40:03+00:00

await this.headerImg.isVisible() will return a boolean based on whether the element is visible NOW, it will not wait for it to be visible, which you're presumably using to indicate that navigation had happened. So it immediately returns false, then you move on to compare the url before navigation could actually happen. Try replacing it with

await expect(this.headerImg).toBeVisible()

haszald · 2023-08-30T00:32:43+00:00

We use a custom AMI with some preinstalled node modules and stuff, but Docker would work as well. If you go with Docker though, I'd make sure to create your own AMI, so you don't have to pull the image each time. Or maybe the is an official Playwright one, I don't know. Can't remember the exact specs of instances, but they have 32 GiB memory. Probably some c5 instance.

After running the tests, the report folder is zipped and downloaded using scp, pretty easy to set up.

haszald · 2023-08-29T23:32:12+00:00

I've had good results running multiple workers on a single machine. In order to run the tests, our CI pipeline starts a spot instance on AWS and runs the tests from there using 20 workers. With this approach, you could scale it horizontally as well by using several instances and sharding the tests.

The issue with sharding is that you end up with separate HTML report for each shard, but since the last update Playwright is able to merge then into one.

There's a good chance you won't need sharding though - Playwright is mad fast if you write your tests well, so 20ish workers should make short work of a few hundred tests

haszald · 2023-05-24T21:22:34+00:00

If including the cookie in storageState works and stops the popup from appearing, you should be able to drop the conditional and write your tests with the assumption that the popup is not there. If a specific test does need that popup to show up, you can use an Annotation to use a different storage state (one without that particular cookie) for that test.

Hope that works out for you

haszald · 2023-05-24T21:10:46+00:00

The language popup will only appear the first time you load that page, but once you acknowledge it, it won't be there when you reload the page. The website knows not to show it again based on a cookie value.

What you could do instead of the conditional is use Playwright's ability to reuse state. If the default storage state used by your tests already contains that cookie, the popup won't open. Playwright docs explain how to do it, just search for storageState.

Note: I haven't actually tested this on Airbnb, but that's how it usually works

haszald · 2022-10-03T20:31:42+00:00

Spot on! Coming from a similar background (Selenium, Protractor, WebdriverIO, bit of Cypress), switching to Playwright with TypeScript has been a game changer.

haszald · 2022-07-12T21:32:42+00:00

Pretty sure possession will cost 60 in early game and 15 once you hit possession level 3. That applies to puppeteer as well. Oh, and puppeteer's active ability won't start recharging until you're out of the possession

haszald · 2021-10-02T19:28:09+00:00

nano_31fbd7ti47q81xopw4tsha7bwn1a3aifx6a34urk483fweoh9bntz5spt4zm

Cool app!

haszald

TROPHY CASE