maktouch

I have a GBD-200. battery life is like 2 years lol. the notifications aren't the most reliable... sometimes it disconnects and I'm not sure why.

We use https://crisp.chat

There's some small quirks to iron out but overall, great product, super great price.

I'm pretty happy with XSplit VCam (https://www.xsplit.com/vcam)

Do you have any USB-C hubs attached to it? It happened to me, and it stopped when I switched hubs (tried over 4 of them)

We're working on the OSX version.

If you need it for real-time video calls, check out XSplit VCam: https://www.xsplit.com/vcam

We're a little bit too locked to GCP to migrate out.... But I'll definitely stop evangelizing GCP to people.

I have now lost faith in you, GCP.

If you are really trying to understand the psyche, you would be more open, ask more questions, and be less judgy. Telling people to go hug a tree is not how you understand people, and it does make you look bad.

I'm in the same boat as you, tho. I'm in the video game streaming industry... I don't understand at all how people actually watch other people play video games, and I do think there's benefit to disconnect.

Same here. https://borderprivacy.ca/

Signed and donated. It happens to me every, single, fucking, time, losing 1 hour every trip back home.

Database migrations for RDBMS like mysql or postgres, we use knex or laravel's database migrations tools.

For bigquery, we wrote this nifty tool https://github.com/SplitmediaLabsLimited/supermigration

You don't need to use gcloud to ssh. Just add your keys in your projects' Metadata, and you'll have ssh access to all servers.

Each member of your team can do it, and it works retroactively.

Well, UX means user experience. If some little features give you a better experience to me, a user, isn't that a better UX?

They both have regions. One makes it easier to see at a glance.

They both have the concept of reserved IP, one doesn't need to be set first.

They both install ssh keys for you. One does it per user, the other per instance.

One sets up cross region VPC for you. The other one makes you suffer and do it yourself.

In GCP, I çan see all my instances of all regions in one go. I can't do that with aws.

In GCP, I can easily create networks between projects. It's really shitty to do in aws.

In GCP, I can create a machine and everyone in my team automatically has ssh access.

In GCP, I can make an instance, then mark the IP as reserved. In aws, I have to reserve the IP first.

Aws UX is the worst. I use both on an everyday basis. I could go on and on..

We solved this by using persistent queries that maps it like

/graphql/{queryname}/{hash}?{params}

Multiple advantages:

1) client doesn't need to send the whole query unless it doesn't exist. All of this is handled automatically.

2) http caching of queries are now possible since it's a get instead of post

3) we can check slow queries using similar tools as rest. When we see a query being slow, we check each resolvers. We usually keep the queries simple

If you had shit on your arm you'd just scrub it without water?

Filipino uses a system called tabo, or sometimes a hand hose bidet (I call it the bum gun). If the pressure of bum gun is strong enough, well, it's like a pressure gun. You shoot it at 45 degrees angle (cause 90 hurts lol).

If the pressure is not strong enough, then use it like tabo. Tabo is a water scoop. You water your hand, you water your butt, then you soap both of them, and wash it out. It's a shower but just for your butt.

This sounds a little bit weird and disgusting but it is the cleanest since it's like a shower. Nothing beats a soap and scrub.

If there's tissues, take a tissue, pat down your butt so it's dry, put it in the bin.

Hope that explains it!

I remember using FullCalendar when it was a jQuery plugin about 8-9 years ago, it was slick and it worked very well.

Thank you for doing this.

We moved from Gitlab CI to Buildkite

1) We moved from Gitlab to Phabricator and Phabricator CI sucks so much, we integrated buildkite with it instead

2) We quickly realised that Buildkite UI is superior, but also its runners. You can add custom extensions to Buildkite and make it do whatever you want https://buildkite.com/plugins

We never had that issue with node

With Phabricator, yes, you can setup herald rules that stops a merge from happening if a file has changed in a specific subdir.

We use service owners, so when a change spans multiple services, they are all added automatically as blocking reviewers.

The equivalent would be spot instances on AWS.

They're equivalent in the sense that you have nodes that can die anytime, but it's much more complicated. You could technically have a much lower cost on AWS by aggressively bidding low but we've had a few instances where the node only lived a few minutes.

Preemptibles nodes are max 24h, and from our stats, they really live around that amount of time. I think the lowest we've had was a node dying after 22h.

You also save out of the box because they apply discount when your instance is running for a certain number of hours.

You can even have more discount by agreeing to a committed use which you pay per month instead of one-shot unlike AWS.

I'm going to add a few more reasons to the above reply:

- UI and CLI is so much better in GCP

I don't have to switch between 20 regions to see my instances/resources. From one screen, I can see them all and filter however I like.

- GCP encourage creating different projects and apply same billing.

It's doable in AWS too, of course, but coupled with the fact that you have different projects and regions, and you can't see all instances of a project at once, this makes a super bad experience

- Networks are so much better in GCP

Out of the box, your regions are connected and have their own CIDR. Doing that in AWS is complicated.

- BigQuery integration is really good

A lot of logs and analytics can be exported to BigQuery, such as billings, or storage access. Coupled with Data Studio and you have non technical people doing dashboards.

- Kubernetes inside GCP is a lot better than AWS'

https://blog.hasura.io/gke-vs-aks-vs-eks-411f080640dc

- Firewall rules > EC2 Security Group

- A lot of small quality of life that makes the experience a lot better overall

... like automatically managing SSH keys for instances, instead of having a master ssh key and sharing that.

Here's the thing though, a lot of GCP can be replicated, just like what you linked for the identity provider. With GCP, there's a lot of stuff out of the box -- so dev and ops can focus on the important stuff.

Overall, AWS is just a confusing mess and offers a very bad UX. Moving to GCP was the best move we've made.

We pretty much run 98% of our stuff in preemptibles. It's a free chaos monkey that makes your stuff cheaper too!

Just make sure your app has proper probes, and make sure the probes returns 500 when the process receives a sigterm, and it should be invisible to you.

Instead of hitting our ingresses / load balancer, we made it so that webhooks hits a cloud functions, which then transform it to a cloud pubsub.

We listen to the cloud pubsub from a worker.

1) we don't manage it. We receive quite a lot of webhooks and it's nice to offload that 2) all of our webhooks are async. We just have 1 worker that handles it all, instead of provisioning a bunch of pods. 3) managing cloud functions is dope, since you can make it autodeploy from git.

10/10 would use again. Not sure about building a whole app around it tho

While transitioning away from Redux, we actually fetched Data via GraphQL and put it in stores.

Honestly, it was a pain, but it's because we abused Redux.

We progressed by doing the HOC and bypassing Redux but it still was a pain, because HOC.

We're now at a stage where we updated Apollo versions, and started converting to the Query components. It feels and work a lot better.

When we started, we thought the same thing -- keeping data fetching separate from the view layer if possible. We realised that it didn't make that much sense. Keeping everything in React components is a lot more maintainable and easier to comprehend.

Sure!

Our implementation is a little bit naive - it doesn't "clean out" or see which resources are being used.

On the frontend:

There's a script that globs all `.graphql` files and compiles them into a list of {query, variables}. This probably could be made better if it was a webpack plugin that compiles this on build time. This was a Friday project so our time was pretty limited. This was honestly good enough since it caught a shitload of bad queries =).

Query contains the graphql query. Variables contains test arguments.

It saves them into a gigantic file (example: https://gist.github.com/maktouch/074339517a8da5128d62869356b...)

On the GQL server:

We take that file, we parse it, and we loop it and pass it thru the validate function (https://graphql.org/graphql-js/validation/#validate)

(truncated example: https://gist.github.com/maktouch/e1a2955dfcca42541a41665a361...)

Ops:

Frontend and GraphQL are its own Docker image. We build both in parallel. When both succeeds (in building and running their own tests), there's an extra build step that runs this specific test. It does it by taking the gql-queries.json file from the frontend container, adding it to the GraphQL image, and running the validate command.

You can do this by doing multi-stage builds in Docker (https://docs.docker.com/develop/develop-images/multistage-bu...). We don't push the resulting image - it's just there for testing.

I'm starting to understand what you mean.

You are right - GraphQL, even though it has the word "graph" in it, is pretty weak at complex graph traversal. Actually, I don't think it was made for complex graph traversal in mind.

https://docs.dgraph.io/master/query-language/ uses graphql, but they really modified the language to make it work for complex graph traversal, to a point where the simplicity of it is gone.

Hey, that's cool! Thanks for that, will try it out on a new service/pet-project one day.

In our current service, I think we're pretty happy with the way our structure is. It's almost similar to saturn-gql but with raw javascript instead of parsing with `graphql-tools`.

My understanding is the json type stuff is a language specific workaround and not part of the standard.

The standard is made to be extended (https://www.apollographql.com/docs/graphql-tools/scalars.htm...)

For example, you should start with making your own DateTime scalar.

What I sort of what is to be able to craft a query against a large set of objects like a customer/location/asset hierarchy and filter on different levels like sql query without it being in a database.

You can totally do this without raw json scalar. Actually, it would be better without it.

If you could go more in-depth details, I could make you a PoC.

We deployed our GraphQL July 4th 2016. It'll almost be 2 years. Documentation sucked back then (and apollo was non-existent), so a lot of we had to dig by ourselves.

I hope this book will cover some topics for others that was real head scratchers for us

- DataLoaders

- Authentication example

- Unions and Interfaces are your friend. Use them early.

- Try to define your custom Scalars early (especially DateTime format)

- return Connections (edge/node) instead of List cause you probably want to paginate at some point

- Folder structure (we redid ours 4 times lol)

- Naming convention (we redid ours 3 times lol)

- Subscriptions

After 2 years of using it and hacking it, we're still impressed. Once you get past the learning curves and have set conventions, writing GraphQL is a lot faster and better. Define your types, and some custom root queries, and done.

The neatest thing is that we made a schema validator -- compile all the graphql queries from the frontend and mobile, and validate them against the server schema. It really help when we changed folder structure and naming convention to see if we'd break something on the frontend.

I can't vouch for this book yet, but I'll swear my life on GQL. It's been a real game-changer.

Hmm, our API is pretty big and we never had an issue where GraphQL couldn't solve it (https://player.me/api/graphiql)

I don't see how I can implement complex object hierarchies that are not rigid.

I'm not sure I understand what you're trying to do, but did you try the JSON scalar type? https://github.com/taion/graphql-type-json

With that, it just returns JSON but you can't pick and choose what keys gets returned.

We never had to use that though. We prefer to use interfaces or unions.

I like the abstraction of patches, because some of our projects still runs SVN and HG, and because we're all on Phab, we're all using the same flow. We actually don't feel any urge to move to git at all (it's probably going to happen some day anyway)