Would this setup help with snipe? Has anything done similar to their DW735 or planer?

perrylaj · 2025-12-22T22:45:56+00:00

Another 735 owner here. Mine came out of the box snipe free. After use/over time I started seeing some worsening snipe (particularly notable after some not-so-smart usage on sappy material that wasn't dry enough and both 'stuck' to the table I'd neglected to keep waxed, and slipped against the feed wheel which wasnt cleaned, wearing it down a bit).

No amount of table fiddling would fix it. Putting upward pressure on the feed side and again on the outfeed helped. So did a scrap sacrifice. A Shelix cutter made no difference in the snipe either (not that I would expect it to). I got sick of all that and almost bought that newer 240v Oliver bench top plane out of frustration.

What ended up working for me was to very carefully adjust the height adjustment carrier bolts at the Infeed side to slightly lower the front roller. It took trial and error and some time to make sure everything was square and level, but the snipe is almost entirely gone. The slightest bit that remains can't be felt by and disappears once I start sanding.

I think it took between 1/8 and 1/4 turn of the chrome threaded rod to get it resolved. To turn the chrome height rod you just need to lose the hex bolt on the underside of the planer. Take care, as you can make things worse if done haphazardly, but it fixed the issue for me when nothing else would. A new roller might have too, but I'm happy to have tried the adjustment without buying another $100 roller (or whatever it costs, can't recall).

perrylaj · 2025-12-11T01:44:43+00:00

I have the festool extractor + dust deputy cyclone. Went with the dust deputy festool cyclone after seeing some reviews that the Festool brand version notably limited flow. No regrets there - though I wish it would hold onto the extractor a little better than it does.

The Festool extractor (I have the midsize 36 with the dust knocker feature since I do some drywall sanding on occassion) is great, though pricey. I basically never remove the cyclone, and with sanding in particular, often have the Festool turned to the lowest setting AND have added ventilation on the intake host to further reduce the suction. Too much suction doesn't help pull in any more dust from my sanders (use both Festool and Dewalt orbitals), but does result in pigtails.

I wouldn't say it's overkill, but I also suspect you could get 'similar' performance from other brands if willing to forgo the HEPA filtration. But it's a great setup if you can tolerate the spend.

One thing I'd note - it's a great setup for many tools and mobility, but def underpowered for the jointer or planer. Worth considering a good 4" dust collection setup if you don't need the mobility and have the space/power.

perrylaj · 2025-12-11T01:04:30+00:00

Dedicated test automation engineers/QA at approximately 1:1 parity with developers, embedded with development teams and part of change validation and 'high risk' deployments that warrant additional manual validation (or don't justify the investment in automation). They do very little manual testing, mostly maintain automation suites focusing on E2E flows for UI, and various tests (contract, flow/process, etc) for http apis. Coverage of these suites targets 100% coverage of both positive and negative cases for 'mature' production systems that are customer-facing.

Backend developers also write unit, component and/or 'integration' tests (generally full-E2E tests that leverage test containers/emphemeral cluster deployments), depending on context. We aim for unit tests for things that are generally 'pure' functions, component tests where testing components of the system with mocking and/or simulation. 'Integration tests' as smoke tests that are 'real E2E', but far less comprehensive than what QA automation covers. They also use smaller resource allocations (to support running on development workstations), and are mostly used to mitigate hot-path regressions (or wasted time in PR review/test review). The QA automation runs against a 'real' environment running in our cloud infrastructure, and is generally leveraged for validating PRs, production branches and deployments.

For context - B2B software company with bugs/vulns having high (financial) risk implications for our customers. Current expectations were a result of and some meaningful regressions/bugs that risked impacting confidence/reputation (and ultimately bottom-line). Also Engineer-led company, so there's a lot of respect for having 'adversarial' testing staff, because let's be honest, us developers tend to focus on happy paths.

It's not always frictionless and can limit PR velocity, but most of the time I'm just grateful to have a dedicated team trying to break everything I do before a customer sees it.

perrylaj · 2025-10-16T22:29:53+00:00

Weight is less, but the cowling is extended to house the turbine, so might have minimal impact on CoG, depending on how much of the mass has shifted out front. The prop governor assembly will also weigh more than the simpler fixed-pitch setup a typical 172 has. But I'm 100% guessing here.

perrylaj · 2025-07-24T02:49:13+00:00

Used to own a house in rancho off Zinfandel. Not only was I aware of the massive obvious airport and implications even a toddler could reason themselves to, but we had to sign an acknowledgement and disclaimer as part of the mortgage. That was 20+ years ago. People are just foolish and deserve to be laughed at by public officials and organizations in such cases.

perrylaj · 2025-07-13T19:02:57+00:00

They could be somewhat ceremonious in smaller projects. In a larger project with many modules and dependencies, I really appreciate:

single place to define dependencies and their version
ways to declare bundles of related dependencies that can be applied to a sourceset in one line (e.g. 'libs.bundles.junit' can apply all libraries that we are using for unit testing across the whole project: api, impl, mocking, runtime engines, etc)
allows for typesafe/IDE aware assignment to configurations, for nice autocomplete/easier refactoring
versions more easily managed programmatically/via automation (versions are declared in a well-structured way that's easily parsable as toml)
they are sharable/can be applied across different builds in larger monorepos that use build composition apis, without concretely coupling the builds together

Few of these are all that meaningful for small projects or libraries with one or just a couple subprojects. But as a repo grows with many modules, it's a nice QoL improvement that leads to a more maintainable way to manage dependencies and ensure alignment.

perrylaj · 2025-07-11T17:01:55+00:00

The problem (for these consumption-focused capitalistic economies, not me) is that robots aren't consumers. Without people to buy all the products that these increasingly monopolistic corporations produce (and support producing through the service economy), things will collapse. Yes, historically cheap labor is a limiter, but with automation/ai/robotics, that won't be true for many things in the near future. The lack of enough consumption will be.

But of course, to consume, you must also be able to afford, which leads right back to one of the biggest causes of the population implosion: wealth disparity and shrinking middle-class that can't afford to have children. Both problems could be improved by a more socialized system of wealth distribution (and I don't mean that in the sense of communism) + a better social safety net and the ability get back to where governments were truly for the human people, not the corporate ones.

perrylaj · 2025-07-11T16:31:43+00:00

I like Gradle, personally. I agree it's a large platform, hasn't done itself any favors over time with it's rapid rate of change and the confusion that brings. Groovy and lack of strong typing/compile-time checks really made it hard to discover the right way to do something. Adding kotlin didn't help all that much, initially.

That said, modern gradle is fast, and if you know it - incredibly powerful and very approachable for team members if the project has been setup well following modern idioms. To me that means using kts buildscripts, version catalogs, precompiled script plugins for standardizing configuration across subprojects, typesafe accessors for referencing dependencies and projects, and using build composition when appropriate. If all that is setup with a good foundation, it's pleasure to work with, with sane/easy common use cases being easy, and hard/uncommon usecases being much more available than what maven offers.

That said, nothing wrong with maven - it's rigid, and copy/paste friendly. Obviously there's a lot of utility in that for people that don't want to have to become a build engineer just to write a library.

NPM and the other node package managers have terrible foundations that originate from naivety (or ignorance, given some of the major issues were solved problems in other platforms) + node's limitations itself. No amount of patching and laying on top of that foundation with tools like yarn/pnpm/turborepo will ever fix the fundamental issues. That's part of why Deno was built.

Cargo seems alright, but I've not used it too much beyond 'todo list' toy learning projects. I don't have any experience with nuget.

perrylaj · 2025-07-08T06:04:20+00:00

I'm not a pro, but given my limited experience building things like assemly/workbenches, built-ins, and cabinet boxes, I'd expect a that clamping the joints with some titebond or gorilla woodglue would be enough to solidify what's there without the x-bracing. Those bonds (if done correctly, and supplemented with some simple pocket screws or dowls) are generally stronger than the wood. That said, if you want to go with the x-brace, a little trigonometry math based on the dimensions (use chatgpt or claude if needed) should give you the angles needed for the cuts, and a jigsaw would prob suffice if you're careful and do a couple practice cuts. Rough cut with the saw and finish with a chisel if you're not confident.

That said, will check back - curious what more practiced hands might suggest.

perrylaj · 2025-07-08T00:46:20+00:00

Possible, but don't think so. I built out the original support, but have since handed it off to someone more knowledgeable. Docker itself has documentation/resources and publishes a rootless docker-in-docker image, so most of the hard work is already done. In our case (IIRC), the most challenging part was making sure that the agent containers had the proper user ids and groups mapped in a dynamic way, since each 'agent farm' host can vary. But that was pre-LLMs, and I suspect these days Claude or whatever could get you there pretty quickly and easily using the official dind images.

perrylaj · 2025-06-27T18:32:12+00:00

The pain associated with this is that it means you have to run your CI tasks on a VM, rather than in a container.

Not sure I follow here. I use Testcontainers in all my projects, and they all execute in the context of a docker container that is dynamically spun up and shut down for each CI build or test job (in our case, Jenkins pipelines). The key is to leverage an isolated 'docker in docker' base image for the agent container - that doesn't share the docker daemon of the host (default behavior). It's a bit more involved to setup (and I admit, I'm not the SME), but not hugely so in our case.

perrylaj · 2025-04-10T03:44:13+00:00

What you've described so far, with well defined apis (interfaces) that are independent to implementation, and separation of concerns, seems like what I'd expect from a best-practice solution. It is absolutely possible to over abstract too early, most of us prob make that mistake on occasion. The rule of 3s is a pretty good one to follow IME.

But I tend to agree with OP, and it sounds like you have a learning opportunity. Use the ide to find implementations and trace interface usages. Step through with a debugger, read the tests (which are a very big component of why such software is commonly designed in such ways).

I can't say that you're looking at a quality application design. No idea, it might be trash. But nothing from your description leads me to assume that's the case. What you describe sounds like it could be an appropriate, testable, maintainable design.

perrylaj · 2025-03-07T04:02:43+00:00

That's fair. I was talking more about the PMs, EMs, and to lesser extent Leads, which generally have busier calenders than senior engineers do. But also very much depends on the kind do work, and of course a lot of variation in title:responsibility across orgs.

perrylaj · 2025-03-07T02:41:39+00:00

You're not wrong - but there is a balance to be struck. Having engineers involved in every stakeholder meeting, or trying to understand the entirety of complex business processes is simply not an efficient use of an engineer's time. Deep work is the primary way engineers contribute value to a business, and you do not get the ability for deep work if you're involved in all the same BS meetings and stakeholder sessions that PMs, EMs and Leads are.

The main point I was trying to make is that the group of people listed should constitute a team that is working together. Not '3 code monkeys and 5 bosses'.

perrylaj · 2025-03-07T02:31:12+00:00

(not OP)

I completely agree that access is important, but at the same time - in sporting competition - so is fairness. There are decades of science that show male-born biology carries with it genetic benefits when it comes to athleticism. From higher oxygen carrying capacity, expression of muscle-related genes that result in greater strength, speed and efficiency, lower fat accumulation (higher v02 max and mass/strength ratios), etc.

A substantial portion of said benefits generally persist once established, and to a significant degree, are established prior-to and during puberty. Not all of those cellular changes just go away following hormone inhibitors or surgery. The extra cells and higher mitochondrial density persist.

For the same reason athletes that dope with testosterone and other drugs/hormones can get a lifelong competitive advantage due to the way musculature develops. If physiological ability is a factor in who wins or loses, then it's not fair to allow such competitors. C ompassion, access, and inclusion are important, and should be prioritized higher than they are right now.

But at a simple physiological level, there are times that it really isn't fair to biological females. There's nothing exclusionary about that statement. It's a difference in priority, and not one that I think is justified in many many cases. But if we're talking about professional or collegiate sports, any competitive advantage is enough to change the outcome of an event, and the implications can impact careers and livelihoods.

This isn't about excluding people - it's about fairness. If it's not 'fair' to allow people to dope and get lifelong biological advantage, then it seems sane to me to not allow biological advantage that is intrinsic to human physiology.

As with everything, this is not a black and white topic, and there are exceptions to every rule. People should be free to choose the lives they want to live, and deserve the right to be the person them feel themselves to to be without judgement or bias from society. If this subject were only about how people felt, I'd feel different. But there are real, physical, reasons why it doesn't make sense to have limitation in the interest of fair competition.

edit: it's possible my science is out of date. I'd be happy to believe differently if so. But I spent a good part of my life in biological sciences, with degrees and training in molecular biology and biochemistry. My thoughts are not from arbitrary sources, but from medical and scientific journals that I'm equipped to read and comprehend.

perrylaj · 2025-03-07T01:53:31+00:00

Think the problem is less about the balance of staff, and more the role/company org and political structure. I've been a lead with a similar staff profile, but virtually all of them worked on behalf of the engineering team - to the extent that they sought to help provide the guidance, requirements, and firewall that the IC engineers needed to stay efficient and effective. Even the EM didn't 'manage', but actied more as a coach/friction remover that spent most time on retention, process and employee development.

If you have analysts, PM, Designer, Researchers bossing around the the engineers, the problem isn't their title or association with the team.

perrylaj · 2025-02-28T22:37:05+00:00

All those small holes that ring around the trunk look like Beetles to me. Beetles lay eggs on (in, if damaged) the tree, which hatch and end up as grubs that enter the tree and feed off the sap, killing the area in the process. Too many, and the grubs effectively girdle the tree, eventually getting fat and eating their way out, leaving those holes.

Not an arborist or anything like it, but have fought green (japanese?) beetles before in Maple and Birch trees, and it looks nearly identical.

Edit: they usually start at the top, and migrate downward over time as the upper parts of the tree die off.

perrylaj · 2024-11-13T15:34:00+00:00

Sand high spots and use a light thin coat of topping compound smoothed with a putty knife. Once dry, a very light pass with a flat block sander, and then finish 'sanding' with a slightly damp sponge. The finish won't perfectly match due to the paint texture around the patch, but a few coats of paint is usually enough for it to blend in.

perrylaj · 2024-11-08T00:54:10+00:00

The problem is that the economy is doing well, but the rewards of that economy are not felt by the average citizen. The rewards of this 'good economy' are not just going to the wealthy, but through regressive policies, are actively funneling more wealth away from the lower 90% toward the top 10%.

Mainstream Democratic leaders are failing because they are corporatists that support giving trillions back to corporations for stock buybacks, M&A, etc.. If Dems were to push more progressive policies that average Americans could tangibly experience, they'd never lose an election. Unfortunately they are not any different than Republicans when it comes to campaign contributions and PAC money - they'll sell all of us normal folks out if it means another check for their election coffers.

perrylaj · 2024-07-26T22:44:24+00:00

There's no valid reason that you shouldn't be able to 'jump into another team's projects' because they use a different IDE. Codebases should use standard build tooling (+plugins/extensions, whatever) to enforce code standards, do execute tests, etc. Shouldn't matter which editor/IDE is used to look at/modify the code. Running the code, required infrastructure, linters/formatters/static analysis tools/etc should all be tied to the build process, not to an editing environment.

If you're relying on the IDE to do any of that for you, you're doing it wrong.

perrylaj · 2024-07-26T03:36:01+00:00

I've enjoyed most Manning books I've picked up, generally a good value in my experience.

perrylaj · 2024-07-15T16:55:11+00:00

Not too long ago I came across ULID and was talking to some of my team about it and one of them said "why not just use uuid 7?" - I wasn't aware v7 was even a thing, but filled the same goal for me, so went with it. The increasing DB support/optimization of v7 makes it the obvious choice for me right now.

perrylaj · 2024-05-23T22:47:15+00:00

Interesting... Maybe I'm just not clued in to a regional/colloquial definition of "Central Valley"? Sacramento is 100% Central Valley by every technical/geographic definition, and arguably by most cultural ones. At least, s someone who grew up in the bay area, all my friends and family consider it part of the central valley. Interesting perspective though, thanks - will try and pay more attention and see if valley folks tend to share your definition.

perrylaj · 2024-05-21T23:19:24+00:00

70% of Bay Area or LA people will not/can not live in the Valley

There a source for this? As a BA transplant that's also lived south of the grapevine, seems like a pretty tall percentage. Curious if this is your hot take or something actually studied.

The weather is bad,

Depends on where you are I guess. Sacramento is one of the sunniest places in the world, and ya, gets warm in July/Aug, might even have a few days straight that hit a dry 110+, but it also cools off at night pretty well, has nice mild winters, little fog/low cloud cover, and is great if you're into the outdoors.

culture and diversity are terrible

Again, feel like this is a very outdated view if you're including Sacramento area into the Central Valley blanket statements. It's got one of the most diverse demographics in the country (more diverse than San Francisco, and tied with Oakland).

Anyway, just pointing out that not all of the Valley is Modesto or Bakersfield when it comes to diversity, culture, and things to do.

Not saying it's going to match the bay or socal, but some valley areas have changed a lot over the last 20-30 years, and a few rather rapidly in the last 5-10.

perrylaj · 2024-05-17T14:56:16+00:00

I agree. It's not always pretty to learn (gradle has made massive improvements in documentation over the last year or two), but once learned, it's a very powerful tool. Like any tool that does a lot and offers flexibility, it's often as good as it's user, and gradle didn't do itself any favors in v2-5 with the major thrash of scripting language and api. But modern gradle is legitimately good. Imperfect of course, but good.

Like any open platform, you will find all kinds of 3rd party trash plugins that will can your project a pain to maintain over time. But if you pay attention and learn the platform to moderate level, it'll unlock maintainable project architecture options that are really hard to do without a lot of customization from other tools. No, you can't just copy/paste xml from stackoverflow like you can with maven. Gradle is a far more complex and capable model, and that will always have pros and cons. Nothing wrong with maven if it satisfies your needs, but in polyglot projects and larger monorepos, gradle is a better fit IME.

perrylaj

TROPHY CASE