aspett (u/aspett) - Readit News

aspett commented on Original Prusa MK4 prusa3d.com/product/origi... · Posted by u/oztamir

tcoop25 · 3 years ago

I just canceled my X1-Carbon order. Just spend some time on the Bambu Labs subreddit and you will see a lot of frustrated owners. It is insanely loud, and it seems unreliable and buggy.

I have owned a lot of printers over the years, and the only printers I, or any of my colleagues come back to are Prusa printers. They are incredibly reliable. The few times we have had issues with a part, we have been able to print a replacement. I am constantly excited by fancy new printers that all promise to be the next big thing, and stupidly keep buying them.

I will take Prusa's amazing customer support, a product I know I will be able to upgrade when they release the next iteration, and the company that has the best free software as well (the Bambu is just a forked version of Prusa's slicer).

aspett · 3 years ago

Here's the thing, though: It's almost definitely a case of silent majority. The printer is pretty phenomenal and I've had excellent support from Bambu so far in New Zealand, no less.

aspett commented on Algebraic Data Types in Elixir blog.appsignal.com/2022/0... · Posted by u/unripe_syntax

throwaway932432 · 4 years ago

> We Elixir programmers usually don’t think in terms of sum types.

yikes

Elixir is one of many languages that are red flagged in my job filter.

I conditionally allow python where python >= 3.10, and ruby where sorbet is strictly enforced, )perhaps I'll make an exception for dialyzer)

I'm bullish on golang being in my filter for years to come..

Also I feel that people that care about ADTs wouldn't be using Elixir in the first place, so the evangelism feels wasted here.

aspett · 4 years ago

> We Elixir programmers usually don’t think in terms of sum types.

This person speaks.. for themselves only.

> perhaps I'll make an exception for dialyzer

If your opinion is to disregard Elixir, then dialyzer shouldn't change your mind. It's pretty ineffective and painful to use.

That said, I'm a big proponent of Elixir; it's a great language and makes me happy to use it.

aspett commented on How to build a low-tech website? (2018) solar.lowtechmagazine.com... · Posted by u/okasaki

kome · 4 years ago

I love the design of this webpage, such a polished look, yet not banal or corporate. It has a strong personality. And it's responsiveness is amazing. That's what good design is about. Also, no JS bullshit. What a breath of fresh air.

aspett · 4 years ago

I detest the colours with the scroll. Awfully distracting.

aspett commented on Initial M1 support merged into Linux SoC tree git.kernel.org/pub/scm/li... · Posted by u/_xrjp

kreetx · 5 years ago

A 2015 mbp works pretty well, are there problems with the newer ones?

aspett · 5 years ago

2015 was the last year they worked well.

aspett commented on New report on Apple’s VR headset: 8K in each eye, potential $3k price tag arstechnica.com/gadgets/2... · Posted by u/CharlesW

fuzzybear3965 · 5 years ago

Why will it need to be 90 or 120 Hz?

aspett · 5 years ago

You need a high refresh rate to keep convincing your brain of the illusion. If you dip down to 60hz and below, VR sickness can be a real problem.

aspett commented on When Asbestos Was a Gift Fit for a King daily.jstor.org/when-asbe... · Posted by u/onychomys

PHGamer · 6 years ago

is asbestos really that bad? or is it the long term affects. if charlemagne just used it a show off thing in the diner would it have really mattered?

aspett · 6 years ago

Yes. Breathing it's fibers can cause serious disease and cancer. Asbestos was used as a common building material in New Zealand for insulation, roof tiles, ceiling tiles and texturing and more in the 1950-1990 period. If you do any renovation or changes that interact with asbestos, it basically has to be handled by a hazmat team.

https://ehs.oregonstate.edu/asb-when > When is Asbestos Dangerous?

aspett commented on Prepared statements and their surprising performance implications blog.soykaf.com/post/post... · Posted by u/panic

aspett · 6 years ago

Oh my goodness, you're my saviour. I spent a whole day last week debugging what looked like a caching issue with Ecto + Postgres. When the application ran a query, it'd eventually slow down to 600ms.. when I ran it in psql, always 10ms. My solution was to convert the query to SQL and run it manually which bypassed the plan caching Ecto does.

THANK YOU. I will absolutely be testing this tomorrow.

aspett commented on Promiscuous cookies and their impending death via the SameSite policy troyhunt.com/promiscuous-... · Posted by u/tomwas54

jacobparker · 6 years ago

Yep, that's the issue. I think I see the confusion now (I stand by my original comment).

SameSite=Lax was never an invalid value, so it was never mishandled by browsers (very old browsers gracefully degrade to treating it like None, which is as good as possible). In the original spec there was Lax, Strict, and unspecified (i.e. the Set-Cookie header didn't have a SameSite attribute, the default behaviour) but, critically, no None.

Browsers developed around that time that treated unexpected values as equivalent to unspecified/what we now call None (e.g. Firefox) turned out to have picked a more forwards-compatible approach. Browsers like Safari and Chrome took stricter action for unexpected values (the idea here is a vague "secure by default" feeling) but it's awkward now that the default is changing from what is (now) called None, to Lax.

In that issue, consider the title "Cookies with SameSite=None or SameSite=invalid treated as Strict" redundant: None was an invalid value according to Safari at that time, which wasn't wrong.

SameSite=Lax is 100% safe to set (assuming your site is ready for that). You only need to browser sniff if you're considering setting SameSite=None.

aspett · 6 years ago

I think OP was saying that Safari treats "lax" as invalid, while "Lax" is valid. Note the casing.

aspett commented on Apple Explains Mysterious iPhone 11 Location Requests krebsonsecurity.com/2019/... · Posted by u/feross

Wowfunhappy · 6 years ago

...y'know what I find particularly nuts about this whole thing? That we only know about it because of that location icon in the status bar. Apple could have chosen to hide that icon for certain types of requests, and this story wouldn't exist.

I really hope that after this update is released, someone with checkm8 goes and checks what has actually changed. Not because I distrust Apple per se, but because we shouldn't be making discoveries based on a cosmetic icon.

Also, thank god for checkm8.

Edit: donkeyd, below, reminded me that this behavior is only on the iPhone 11, which isn't vulnerable to checkm8. Sigh...

aspett · 6 years ago

> ...y'know what I find particularly nuts about this whole thing? That we only know about it because of that location icon in the status bar

It seems to me like discovering this from that status bar icon is a _good_ thing. It gives me more faith that the system isn't hiding particular types of calls from the user; that it's tying the system call to the icon being present.

aspett commented on Elixir, Phoenix, Absinthe, GraphQL, React, and Apollo schneider.dev/blog/elixir... · Posted by u/schneidmaster

xlii · 7 years ago

Stack described above is the one I’ve been working on for professionally for the last year and I wouldn’t recommend it.

Main reason is the absurd amount of complexity with costs heavily outhweighting benefits gained from the solution.

For example, simple task of adding new entity consists off: On backend: creating migration, creating data entity (Ecto), writing structure module (sanitization, validation, basic logic, if needed), mounting queries, writing input mutation(s), writing output query/queries, unit testing On frontend: creating component, creating form, writing graphql queries, writing mutation, wrapping components/queries in components, connecting query to components, providing action handlers for inputs, unit testing, integration testing

Now I have authors list. And even though I am full stack I haven’t yet spent even single minute on having Proper UX Design set in place. Oh, do we need to add author’s birthdate? Dang, let me adjust all of that.

In my opinion technical debt accumulates faster than in other solutions. GraphQL is complex. React (done right) is complex. Apollo is complex (Elixir is simple, yet it’s only one cog). Deciding on doing file upload in GraphQL led me to a rabbit hole, which took at least a week to dug out from.

When trying to find the source of all development issues my thoughts go towards GraphQL. Maybe it is too complex or we didn’t had enough experience in it? Yet it was really nice to work with when all the backend and frontend boilerplate was already written. It makes sense, even though requires some heavy thought behind it. Maybe it’s Apollo, which locks in one of two specific trains of thought, or Absinthe, which requires side-hacks in order to get some bit more advanced features working with Apollo, like file uploads or query batching.

From a perspective I’d say this is just too much. Every single part of this stack adds overhead to the other parts. Maybe if I had more specialized team members it would get easier, but being only 3 of us, with me, as a full stack, constantly switching between all of that was a tiresome, low-productive effort. Right now we’re disassembling app to a classic REST-app and we’re seeing development speed increase on week-to-week basis, even though we had to scrap most of the frontend.

I guess there would be some benefit on having the write up of all of it, since it doesn’t even scratch the surface of the year of development issues with this stack, but even in this very "short" form it may serve for a word of warning that this stack is not necessarily something you want to care for.

aspett · 7 years ago

> Maybe if I had more specialized team members it would get easier

It really would be easier. We are using this stack, and have separate backend and frontend devs. Each love their side of the stack. Being backend myself, I don't find the it too time consuming to get new entities going. However, I imagine if you were doing the whole stack and repeating ecto schema, absinthe schema, apollo queries, then it might get more tedious. I particularly enjoy how easy it is to modify the schemas once it's set up too. If we ever need to expose more data, it is usually done within minutes. There is a massive benefit in the forced standardization of GraphQL too. Being rigorous about standardizing APIs and how you do filtering, sorting, embedding, nesting and so on is tiring and a waste of time - you end up writing mini frameworks. Absinthe and GraphQL reduce this pain for us considerably.