jbjorge's comments

"But in the end, it doesn't even matter"

In my case, extrovert living alone. No collab and no meetings with coworkers due to which tasks I was assigned. Just droning on, writing code, with no one to take a break with. I'm still recovering mentally after 2 years of work-from-home during covid - pure mental torture for my personality type.

... and it has not become common knowledge yet that ibuprofen is not recommended for males due to its reductive effect on testosterone production

I used the stack on a side project. Wrote an adapter for websocket sync and a wrapper for Vue that allowed streaming queries.

I really liked it, but the typical pattern of one-db-per-user with internal replication on the server was a bit difficult plan/orchestrate for shared data. I'm patiently waiting for the couchdb PR for document level access control.

These days I use supabase with row level security and a Vue-wrapper that can cache queries locally and update the result as the network request finishes. Works as good as pouch + couch (but naturally comes up short for queries that rely on Date.now())

I discovered that I could control it in my teens. I rather opt for earplugs - the muscle gets tired as all other muscles during use, and the amount of dampening is negligible in my case.

I have the WF XM4 (earplugs) - they have no white noise when not playing. They are garbage for phone-calls though, so wouldn't recommend them if you plan on using the mic.

I don't think it's a limitation with electron on Linux. One time I joined a meeting with an external org, and probably due to some bug in teams I suddenly got more features like e.g. background blur. The next meeting a couple of hours later the features were gone again.

When i used it for web I hit a max of 6 simultaneous connections in chrome. I seem to recall that it was an (intended) browser limitation - but it doesn't throw any errors, so it's not very obvious. I forked the socket-pouch library and changed it a bit to sync unlimited db's over a single websocket connection. It worked like a charm (despite my messy code).

If you're hitting the same issues, this might be it. A non-throwing limitation in the browser runtime.

Hi, author here. Feel free to ask me anything!

Diffx is an attempt at making a library that

* requires as little boilerplate code as possible

* does not require rigid patterns for how to change the state

* has great devtools

* works great with typescript

* works great with react, vue, svelte and angular

It seems the lenses on the quest 2 are a bit of a hit-or-miss and vary in quality between each unit/batch.

My headset had a sweet-spot where the image was clear on maybe 5% of the screen, making it potato-vr for video and text. Others (on reddit) had the same complaints.

If you're considering buying one, make sure you're also able to return it in case the lens-quality of the batch is sub-par.

Since the reactivity api is exposed it's very easy to write a file to hold whatever state you want.

Benefits: easy to create, type safety is simple.

Drawbacks: you don't get a serializable state log for free (that can be recorded and replayed when hitting bugs).

I've worked with projects that used iframes in safari. It had some of the weirdest bugs. Some random times it didn't render changes to the DOM. Sometimes when clicking input fields it would focus the surrounding iframe element.

A webview in iOS could sometimes crash system wide. Not enough to restart the app. You'd have to restart the device.

Felt like a sitcom when I had to ask customers if they'd tried turning it off and on again.

If you use "npm ci" instead of "npm install" there's even less chance of breakage.

The client doesn't over-fetch, but the server might need to over-fetch from the db with generic sub-optimal queries to resolve all the fields.

Your mileage may vary, but on the project at work where we tried to utilize GQL, it became apparant that it sometimes is incredibly complex to map between a GQL query and an efficient db-query.

We're slowly migrating to REST for preformance's sake. The front-end devs might complain since they can't just write a query to get exactly what they want, but I'm quite sure our customers won't complain about 50KB being served in 30ms instead of 10KB being served in 400ms.

If you don't use an issue tracker, then to-dos is your issue tracker.

If you're using an issue tracker as well as to-dos in the code, then you've got two issue trackers.

If you're using an issue tracker that also reads to-dos in the code, then you've got one issue tracker.

Where I work we don't have an integration between the tracker and our code, so we disallow to-dos, but allow comments with references to issues. So in other words - one issue tracker.

I can't quite understand why people would want to have multiple places to list code issues.

Congrats!

We've used ArangoDB for a while where I work, and have only had positive experiences so far. The query language, speed, and flexibility are all nice to work with.

I had the same issue using unity/gnome on a laptop with 1-3 monitors. After I switched to i3 I was forced to set the monitor config manually with xrandr. I set up keyboard shortcuts for switching between 1-3 monitors. This fixed all the issues with automatic window placement since the window manager no longer tries to do this in an automatic fashion.

Tiling window managers definitely have a learning curve, but after I spent a weekend switching to one, I can't see myself ever wanting to go back to floating windows.

In my costly experience - the curves make it guaranteed to crack the glass if dropped from above 40 cm if not using a bulky case. Mine vibrated itself off a low coffee table and onto hardwood floor, cracking three corners. Because of the curves, the cracked glass would fall off over the span of a few weeks, leaving razor sharp shards in my pockets. And don't get me started with the non-existent palm/grip rejection. It takes "you're holding it wrong" to a new level.

Weeeeell, we do have statistics for how civilians drive based on gender.

I probably was a bit unclear. Lets say I've got a family tree stored in a db that goes back 1000 years.

Through graphql I want to find my first ancestor following all mothers backwards. The query would be:

  query familyTree {
    name,
    mother {
      name,
      mother {
        ..and so on for an unknown number of nestings
      }
    }
  }

Dataloader solves batching of the nested query on the server, but doesn't solve the problem of not knowing what the correct number of nestings the query should have.

Of course it's possible to create a new graphql endpoint for this type of query, but then we've just recreated REST in graphql.