Hacker Neue

Preferences
mullsork
Joined 212 karma
[ my public key: https://keybase.io/mull; my proof: https://keybase.io/mull/sigs/S8h4yTrZCar86_lwXf0HjhBjnjq57NojJGEOcMfmruc ]
  1. mullsork
    In the series Babies by Netflix some of her research on this topic is covered. Season 1 Episode 4 "First Words."
  2. mullsork
    > Today the hitbox and damage taken is all dependent on things that do not include aim i.e. if you're one game away from losing, you will likely hit jumping pistol headshots across a map and if you're 4 v 1 trying to close a round, the first person to engage will likely die and you will win with 2 or 3 left standing.

    What? Who told you this?

  3. mullsork
    > I do not permit a woman to teach or to have authority over a man; rather, she is to remain quiet.

    For anyone curious.

  4. mullsork
    > Usually get a new monitor and a new PC every 4 or so years.

    Maybe you're not quite the average consumer that OP has in mind? Maybe you are, I don't know. Either way it's unsustainable and ridiculous that the _average consumer_ would need to replace something after 4 years when it COULD be built to last.

  5. mullsork
    > Refactoring our supabase/postgres repo to improve components and utilize nix for building, packaging, and conducting high-level infrastructure tests.

    Looks like they do mean nix!

  6. mullsork
    Are those schools privately or publicly funded?
  7. mullsork
    JS doesn't have any useful built-in way to deal with success/failure, other than exceptions. We use Boxed[1] for this:

      Result
    .fromExecution(() => schema.parse(input))
    .mapOk(parsed_input => /* */)
    .mapError(parse_errors => /* */)
    which is an alright way to deal with things IMO.

    I would hazard a guess that `parse` is a function introduced long ago, and `safeParse` came afterwards. (Safe as in "do not throw an exception")

    [1]: https://github.com/swan-io/boxed

  8. mullsork
    I open up hanamirb.org at least once per week since the announcement of v2 back in November 2022. Pleasantly surprised to see this new view layer announcement today!

    Anyone using Hanami 2 in production that would care to share their experience?

  10. mullsork
    IIRC that's what oneOf is for. i.e. a discriminated union / sum type. My experience with oneOf is that tooling support for it is terrible.
  11. mullsork
    SQL MERGE looks great! I hope I remember it when the time comes, instead of writing 3 separate queries.

    edit: Postgres docs on MERGE: https://www.postgresql.org/docs/15/sql-merge.html

  12. mullsork
    Congrats! It would be interesting to hear more about the rewrite, 18% code reduction is significant. Have any of the contributors written about it somewhere?
  13. mullsork
    For some reason this does not work with the Vimium browser plugin. Otherwise, very cool!
  14. mullsork
    Seems to me like it's an advertisement for shipit
  15. mullsork
    This looks great! Sign up for the free trial was pretty slick. I'm not sure how well known Klarna is outside of Europe (I know they launched in the US), but that would be my preferred method of payment. Or.. anything but Paypal (and giving my CC information)
  16. mullsork
    I like that definition: the code might be fine as far as code itself goes, but it's still slowing you down as you iterate on the product. Decisions that were somewhat right at the time have slowly started go wrong as new ideas, requirements, and knowledge arrives.

    On backends that comprise a database and an API layer on top I find that the sweet spot of speed + iterability can be found by deconstructing the product into its atomic parts. This boils down to modelling the database so that is as close to "reality" (as seen from a business/legal perspective rather than the product's perspective.) as is comfortable.

    Reality is somewhat immutable (compared to a product.) Deconstructing (not just necessarily normalize) the API entities into small parts that reflect some "real world idea." The product is an abstraction of "reality" and that abstraction may change, but the underlying parts do not.

    Of course once performance comes into account things may be different, but speed is rarely an issue when we start.

  17. mullsork
    Momo Finance | Senior Fullstack Developer | Berlin, Germany Remote | https://www.getmomo.de/

    At Momo we want to impact the lives of millions of people and free them from the burden of rent deposits. We want to change the real estate sector for people for good through the power of technology.

    Tech stack: React, Node, Postgres

    Read more here: https://www.notion.so/Senior-Full-Stack-Engineer-698f87db5d7...

    UPDATE: We are now also hiring FE/BE developers who are not comfortable in a full stack role.

    Backend: https://www.notion.so/Backend-Engineer-44d0295e191d48c3af27d...

    Frontend: https://www.notion.so/Frontend-Engineer-50e6887a33214c7a96b0...

  18. mullsork
    I wasn't thinking about lunch, but that makes sense. It's not as strict or drastic here in Berlin. For a 9-6 office job, I'd say people leave for lunch between 12-13.

    What I'm thinking of in the Nordics, or Finland especially since I haven't worked in the other ones, are the two coffee breaks that are part of the work day. I've worked in construction and the aforementioned tech internship, and this is roughly how the day looks (offices tend to start one hour later):

    - 06:50: arrive early, banter, coffee - 07:00: day beings - 09:15: first 15min coffee break - 11:30: lunch break - 14:15: second 15min coffee break - 15:30: day is over

    I may be off by 15 minutes for the coffee breaks, it's been over a decade since I worked outside of the tech startup bubble.

    Not sure how things are in Finnish startups, probably slightly different? I miss these "natural" breaks though. On the other hand, I do enjoy having my coffee while working as well. :')

This user hasn’t submitted anything.