Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "i cri"
-
Looking at my code for 10 minutes. The switch case is always going to default. Almost about to break my head.
I FORGOT TO PUT FUCKING BREAK AFTER EACH CASE. WWWWWWWHHHHHHHHYYYYYYYYY12 -
[2010]
Begins Bitcoin mining during it's infancy, stops because it's a waste of time and has no value.
[2017]
1 BTC = £5,874
i cri evrytiem ;_;5 -
Anyone know how to go about unit testing an application that is made up of:
- Electron
- Node
- React
- Typescript
(React using Typescript of course).
Electron has its own framework (Spectron), people seem to use Mocha with Node, React has its own tools like React testing library (and testing UI components will probably end me) and Typescript seems to play best with Jest - but a special Typescript flavour of Jest called ts-jest is preferable because the only other option is having Babel and its Typescript support that doesn't type check.
I want to beg for the sweet release of death.4 -
Dear Lord, please stop people from enforcing standards and bypassing them themselves.
Take kubernetes for example. Since v1.24 CRI has been announced as the standard, and kubernetes is shifting to live by it.
But it's not.
Yes, it's got the CRI spec defined and the unix://cri.sock used for that standardised communication. What nobody's telling you, is that that socket MUST be on the same runtime as the kube. I.e. you can't simply spin up a dockerd/containerd/cri-o server and share its CRI socket via CIFS/NFS/etc. Because kube-cp will assume that contained is running on the same host as cp and will try to access its services via localhost.
So effectively you feed the container via a socket to another machine, it spins up the container and that container tries to
- bind to your local machine's IP (not the one's the container is running on)
- access its dependencies via localhost:port, while they are actually running on your local machine (not the CRI host)
I HOPE this will change some day. And we'll have a clear cut between dependencies and dependents, separated by a single communications channel - a single unix socket. That'd be a solution I'd really enjoy working with. NOT the ip-port-connect-bind spaghetti we have now.4 -
When you restore a decade of photographs from your relatives' hard drive and they have no idea that you feel like a hacker from the movies. But as you browse the photos, you cri because damn! It's been years! I miss my childhood!