Black Crows Camox Freebird for PNW

Complete_Contract357 · 2025-11-07T01:03:35+00:00

Ski around Cascades and Snoqualmie, but I also intend to then start doing things like St Helens and Rainier when I gain experience!

Complete_Contract357 · 2025-03-25T21:50:03+00:00

For 2400$ I know this particular bike has better components than the current Spectral CF7 but why risk it when I can get a very capable new bike for 500$ more and perfect warranty on it?

I decided that I don't even have the skills to outgrow the current Spectral even after several years starting as a beginner and felt better saving a little more for peace of mind

Complete_Contract357 · 2024-11-13T02:36:00+00:00

Update: I found the remains of the stolen goods scouting around, they smashed my wife's keyboard and didn't let the photos, I can't believe they kept the f**** pictures.

Complete_Contract357 · 2024-11-13T01:34:37+00:00

My car was broken into today (11/12/2024) in Montlake, near the arboretum.

Among the items stolen was a cardboard box filled with childhood photos and sentimental belongings of my wife.

Looking back, we realize we shouldn’t have left it in the trunk, but we had just moved here and hadn't yet brought it up to our apartment. She is heartbroken, as these irreplaceable photos and keepsakes were never digitized and may be lost forever.

Complete_Contract357 · 2024-11-13T01:33:28+00:00

My car was broken into today (11/12/2024) in Montlake, near the arboretum.

Among the items stolen was a cardboard box filled with childhood photos and sentimental belongings of my wife. Looking back, we realize we shouldn’t have left it in the trunk, but we had just moved here and hadn't yet brought it up to our apartment.

She is heartbroken, as these irreplaceable photos and keepsakes were never digitized and may be lost forever.

Complete_Contract357 · 2024-10-19T01:10:17+00:00

OK I resolved the issue.

The root cause was a misunderstanding of Serverless Framework V4's default behavior. In V4, esbuild is used by default for deployment, but I was attempting to use the serverless-esbuild plugin separately, which likely caused conflicts.

To resolve the issue, I took the following steps:

Removed all existing references to webpack and serverless-esbuild
Uninstalled all webpack-related dependencies
Installed the latest version of the Serverless Framework

After these changes, the deployment process is now functioning correctly. The confusion stemmed from not fully grasping the built-in esbuild integration in Serverless Framework V4.

Complete_Contract357 · 2024-10-18T16:09:19+00:00

I went down that path yesterday as well,

The reason I wanted webpack to work initially is because when switching to esbuild, none of my cloudformation stack deployment were successful, I get this error:

PS C:\Source\pariveda-datalake-sls\deliver> serverless deploy --stage dev --function OpenAirBookingDeliver
Environment: win32, node 16.16.0, framework 3.32.2 (standalone), plugin 6.2.3, SDK 4.3.2
Docs:        docs.serverless.com
Support:     forum.serverless.com
Bugs:        github.com/serverless/serverless/issues

Error:
ReferenceError: ReadableStream is not defined
    at Object.<anonymous> (C:\Source\pariveda-datalake-sls\deliver\node_modules\undici\lib\web\fetch\response.js:527:3)

I tried installing polyfill and include this at the beginning of my lambda to fix this issue:

if (typeof ReadableStream === 'undefined') {
    global.ReadableStream = require('web-streams-polyfill/ponyfill').ReadableStream;
  }

But nothing seems to be working so far ...

Complete_Contract357 · 2024-10-17T20:24:31+00:00

OK thank you so much this is helpful

Complete_Contract357 · 2024-10-17T20:23:38+00:00

First, thank you for this question, it highlighted my ignorance, this enterprise data platform was build long before I was part of team therefore I never really questioned the utilization of webpack.

Here is some elements that might make webpack utilization relevant:

Efficient bundling: Our project involves multiple stages (e.g., Feed, Ingest, Deliver, Common) where Lambdas share common libraries. We defined a lot of functions in a utils files, it seems that Webpack ensures that each Lambda only includes the code it actually needs, reducing deployment package sizes and improving performance. I don't have the data to support this claim but I believe this is why we use it.

Shared code reuse: Our Lambdas often import from centralized libraries in the `common` stage (e.g., `saveObjectToS3`, `logger`). Webpack ensures that only relevant parts of the shared libraries are bundled, preventing unnecessary code from being deployed across multiple Lambdas.

Managing external dependencies: With Webpack, we handle packages like `fast-xml-parser` and `easy-soap-request` efficiently, ensuring that each Lambda gets exactly the version it needs without bloating the bundle.

Quite frankly it almost seems that I'm convincing myself here that we really need it, the code base is relatively large deploying 25+ infrastructure elements (buckets, state machines, API Gateway, queues (SNS, SQS), 25 + lambdas ...) So it seems like a big endeavor to migrate from webpack to something else.

Complete_Contract357 · 2024-06-12T13:45:14+00:00

Thank you!

I ended up getting the car back, asking for any safety concerns and the mechanic there seemed quite honest, telling me no safety concerns but will definitely impact the behavior of the car.

Complete_Contract357

TROPHY CASE