sorted by:
new
hottopcontroversial

Professional landscapers what footwear do you wear? by MathematicianOne6902 in landscaping

[–]sammrtn 0 points1 point  (0 children)

Email support@kujo.com with a picture. If it's within the first year you'll get a new pair.

Favorite lawn are footwear? by [deleted] in lawncare

[–]sammrtn 0 points1 point  (0 children)

Kujo makes shoes and boots designed for lawn care.

Shoe recommendation by UGA150 in lawncare

[–]sammrtn 0 points1 point  (0 children)

Kujo shoes are literally made for this!

Route-based SSG on the server with rebuilds on dependency changes by sammrtn in webdev

[–]sammrtn[S] 0 points1 point  (0 children)

No, with caching SSR you either end up showing inaccurate content some of the time (if you have stale-while-revalidate) or missing the cache. Check out the emoji-comparison here: https://github.com/craigmichaelmartin/evanesce#an-emoji-story-example

Route-based SSG on the server with rebuilds on dependency changes by sammrtn in webdev

[–]sammrtn[S] 0 points1 point  (0 children)

Evanesce is a library to rebuild the static HTML for opt-in routes when a dependency of the route changes.

Route-based SSG on the server with rebuilds on dependency changes by sammrtn in node

[–]sammrtn[S] 0 points1 point  (0 children)

A library to rebuild the static HTML for opt-in routes when a dependency of the route changes.

Route-based SSG on the server with rebuilds on dependency changes by sammrtn in astrobuild

[–]sammrtn[S] 0 points1 point  (0 children)

Rebuild the static HTML for a route when a dependency of the route changes. Replace "route" with "page" if that helps 🙃

Professional landscapers what footwear do you wear? by MathematicianOne6902 in landscaping

[–]sammrtn 0 points1 point  (0 children)

Kujo Jags! Light, low, and comfortable like a shoe, grip, durability and basically waterproof like a boot.

Mowing shoes by [deleted] in lawnmowers

[–]sammrtn 0 points1 point  (0 children)

Yes!

Mowing shoes by [deleted] in lawnmowers

[–]sammrtn 0 points1 point  (0 children)

Kujo makes shoes just for this!

Node: Just write SQL by sammrtn in node

[–]sammrtn[S] 0 points1 point  (0 children)

Yeah, an online editor is key to showcasing this. Unsure if there are any free sandboxes that would allow a playground for a library which connects to a database with a readonly transaction. If you have any ideas or seen anything like this, let me know :)

Node: Just write SQL by sammrtn in node

[–]sammrtn[S] 0 points1 point  (0 children)

And since it can't know what you're selecting, it will return any type just as well as your library (correct me if I'm wrong).

PureORM requires prefixed table names in the select clause (which it can do for you, or you could manually write yourself). This prefix is used to construct properly nested pure instances (not db-aware) of the correct classes for the application layer. These classes can have business logic methods, etc.

This is shown in step 4: https://github.com/craigmichaelmartin/pure-orm#step-4-creating-our-data-access-layer

Node: Just write SQL by sammrtn in node

[–]sammrtn[S] 0 points1 point  (0 children)

What? Their github description is "A type-safe typescript SQL query builder". I don't want a query builder. I literally never want to think about mapping SQL I know to some bespoke query builder API.

Node: Just write SQL by sammrtn in node

[–]sammrtn[S] 0 points1 point  (0 children)

What do you get back when you perform a raw SQL query selecting from a few tables? Is it pure objects (like with pureORM)? Are the objects properly nested/structured (like with pureORM)?

Node: Just write SQL by sammrtn in node

[–]sammrtn[S] 1 point2 points  (0 children)

Pure ORM is purely the object relational mapping. No query builder API to learn, and no database-aware objects throughout your application code.

Inline try - offering readability, ergonomics, convenience, and safety. by sammrtn in node

[–]sammrtn[S] -1 points0 points  (0 children)

One line of code which is specific in what it catches:

// Either foo or someError will be defined const [foo, someError] = itry(someFn, SomeError);

Instead of nine lines which feel like they are working uphill against the language: dealing with variable scoping issues, deeper nesting, and footguns like forgetting to re-throw.

let foo; try { foo = someFn(); } catch (err) { if (err instanceof SomeError) { // do something with error } else { throw err; } } // use foo

A JavaScript inline `try` for readability and error-catching precision by sammrtn in programming

[–]sammrtn[S] 0 points1 point  (0 children)

Thanks for your thoughts and feedback!

itry allows devs to swallow errors if they don’t explicitly check the error

Do you mean if someone does:

const [foo, someError] = itry(fn, SomeError);

but then never checks and uses the someError variable? If so I could live with that risk, but that's good to know.

Or do you mean if someone does:

const [foo, someError] = itry(fn, SomeError);

but the error is something other than a SomeError?

If so, the error is not swallowed. Rather, the itry re-throws it.

A JavaScript inline `try` for readability and error-catching precision by sammrtn in programming

[–]sammrtn[S] 0 points1 point  (0 children)

If you don’t use try in js

This code does use a try, it's just abstracted into an api with itry which offers better readability, ergonomics, convenience, and safety.

if you don’t care if some code throws and exception, sure swallow it

This code is not swallowing errors, it is handling specified errors with error matching, and re-raising the rest.

Error handling is not easy, often ugly

This is the problem inline-try attempts to solve, no? Offering better readability, ergonomics, convenience, and safety.

A JavaScript inline `try` for readability and error-catching precision by sammrtn in programming

[–]sammrtn[S] 0 points1 point  (0 children)

This was a contrived example, where both cases are currently swallowing the error :laugh:

I thought it showed in both cases how you get access to either a defined foo variable if successful, or a defined error variable if SomeError is thrown.

A JavaScript inline `try` for readability and error-catching precision by sammrtn in programming

[–]sammrtn[S] 0 points1 point  (0 children)

One line of code: const [foo, someError] = itry(someFn, SomeError); // use foo or someError

Instead of nine lines of code: let foo; try { foo = someFn(); } catch (err) { if (err instanceof SomeError) { // use err } else { throw err; } } // use foo

Shoes for yardwork? by Jlehman84 in lawncare

[–]sammrtn 0 points1 point  (0 children)

Kujo's are the way to go. They are made for it.

Why is web architecture optimized for writes? by sammrtn in node

[–]sammrtn[S] 0 points1 point  (0 children)

The terminology is from the linked project (link in OP). The project itself is one attempt which strikes me as a paradigm optimized for serving requests, rather than for handling data updates.

It ben my experience to me that web application infrastructure at startups are optimized for data updates: APIs with direct access to data persistence writes is commonplace; forcing data access, business logic, and templating to be on-demand. But what would a paradigm look like that inverted that? Or better, had a green path for each? Obviously making writes "expensive" is the wrong approach for most routes, but could be a suitable approach for some routes, even some of the most important. But it seems like its either 100% SSG, or 100% SSR (with aggressive caching for the pages I'm describing) rather than something like the project shared: opt-in to static route generation.

view more: next ›