jbjorge

"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.

To all considering using graphql, let me tell you something that was unclear to me when I first tried it: If you plan to use it with a schemaless (nosql/graph) backend, graphql will force you to write a schema for it. If you can't (due to dynamic data), you will just end up forcing graphql treat your data as json-blobs with no schema. Graphql turns into a json-blob transmitter with no benefits. Also, if you have deeply nested/recursive data structures, the client performing the query needs to know just how deep it should query. This can lead to ridiculous queries if you're running on a graph db where the client doesn't know how many vertices it should traverse. REST is a better fit if the above is true for you.

This was my experience as well. For two years I lived at a latitude where I got about zero daylight for 5-6 months per year. My SAD-lamp helped a little (<10k lumens), vitamin D helped a lot.

The number of viewers might be a bit different.

...after you've learned the principles of UX.

Maybe he wanted to keep his code hack-free.

When I was searching for a job, I made a CV that looked different and would maybe catch the eye of the poor guy flipping through hundreds of resumés. Worked great for me. Make a great first page/impression, and a regular second page. http://dl.dropbox.com/u/2938449/CV.pdf

Compared to the Oklahoma bombing and the recent theater shooting, Norway probably didn't act all that different, but from reading the source, this is one of the comments that captured the essence of why/how Norway stands out:

"[]...What we Norwegians are afraid of is actually the situation you have in the US and UK either with Police or prosecutors with way too much power or CCTV cameras everywhere etc. We have been a peaceful society based on trust to each other for a long time, and intend to let that continue. I can only quote FDR: "The Only Thing We Have to Fear Is Fear Itself". Stoltenberg actually had to come with that statement. As doing the "US style fixit" would have backfired on him politically. Popular demand is different here, and that is the true power of Norway."