GitHub (Actions) is simply not built to support monorepos. Square peg in a round hole and all that. We've opted for using `meta` to simulate monorepos, while being able to use GitHub Actions without too much downsides.
I do wonder if this really solves the author problem because by the looks of it , you just have to run meta command and it would run over each of the sub directory. While at the same time , I think I like it because this is what I think people refer to as "modular monolith"
Combining this with nats https://nats.io/ (hey if you don't want it to be over the network , you could use nats with the memory model of your application itself to reduce any overhead) and essentially just get yourself a really modular monolith in which you can then seperate things selectively (ahem , microservices) afterwards rather easily.
I've been using openapi-generator for this for quite some time. I love the principle, but find that their generators are not all top notch, and the template-based approach is very hard to contribute to.
One thing I do not see with Stainless is also using it to generate the server side of the API.
We use OpenAPI as a design doc, and generate client SDKs and Datos for the server from the same spec. This gives us pretty solid control over interoperability.
Thats what I used at my previous startup and had a lot of luck with it. Our backend used NestJS which allowed us to define APIs and DTOs using decorators which automatically generated OpenAPI json files. Then our clients would load the json and generate their own SDK as a library. It worked extremely well. It worked so well that I don't really understand what problem Stainless is solving. We didn't ship public SDKs. So, maybe that's what I'm missing, but for our internal clients OpenAPI generators worked great. We generated SDKs on the fly for TypeScript (Node services and Angular clients), Dart (flutter), Kotlin (android), and Swift (iOS). For the most part it all "just worked" for our use case.
> their generators are not all top notch, and the template-based approach is very hard to contribute to.
I agree, I love them in theory, but wrangling mustache templates is a hassle. They end up super coupled to the code that populates them which makes them a bear to modify.
Disclaimer: I work in Norway so pension, health insurance, parental leave, etc. is already covered by the law and is not a differentiator between employers.
First and foremost: remote. Not commuting gives me 2 hours of time. Every day. That makes a profound impact on my life that goes way beyond any kind of financial compensation.
I have a friend that went of rails (schizophrenia) a couple of years back. One day he threw out all his light bulbs because they were listening devices for "the others". Or deleted all the files on his computer that contained the letter X, because it is "the unknown". Paranoia was a LARGE part of his life, in every decision he took.
My friend was experiencing a lot of stress in his life at the time, which the doctors says most likely induced the schizophrenia.
It looked a lot like what is happening with Musk now.
One thing that has really helped me is the combination of remote + pair programming. Having an extra mind to work together is amazing. Doing it remote removes the stress of commute, noise/stress from the office, and allows for relaxing breaks where I can even lay down if I want.
Using note taking frequently, small commits, TDD and drawing diagrams continuously while pairing also helps keep my mind in context and picking up the thread after breaks. Whimsical has been a fabulous tool for this.
I've been of Aubagio before, and now I'm on Tysabri. The difference is staggering. Aubagio gave me tons of side-effects like hairloss, indigestion, increased fatigue and general feeling of being sick. And it still was not able to prevent flare-ups and lesions.
With Tysabri I can't identify a single side-effect. In the three years I've been on it I've not had a single flare-up or lesion identified after MRs.
Something I also believe helps me a lot is simply living in a country with healthcare and strong welfare. Knowing that when it eventually comes to not being able to work anymore, I have public disability pension that will cover 63.5% of my current salary until I reach retirement age (where normal retirement takes over). Having this knowledge removes a lot of stress and despair, which I genuinely believe helps keeping the disease under control.
I'm on Tysabri as well. There have been no documented significant side effects in the US, which is good. Many people have many years between relapses, if they relapse at all.
However, there is additional risk in taking it if you are JC Virus positive.
I do a lot of interviews for my company. We do coding assignments OR let you bring some code. We just want to talk with you about code that you are very familiar with and confident to talk about.
Almost everyone chooses to do the small coding assignment, because they don't have code to bring.
If you get to talking about code (usually after a quick seeding of applications and a 30 minute chat), we will always talk about the code and also give feedback on our impression. So even if you don't make the cut, we hope to provide valuable feedback on why.
For personal project there will not be a TDD so coder not willing to share their existing codes. I rather showcase my skills in a new development than say already done one.
Yeah, in our case the point isn't really the code, but how you reason around it. How able are you to explain the flow of the code. And also reason about choices made.
There is a real treasure trove of things to talk about.
Questions like:
- Why is it like Y?
- What is good and bad about Y?
- Why do you think X would be better?
- Why did you end up doing Y instead of X?
- How would you approach changing it to X?
Discussions like these on both a macro and micro level is very valuable.
The company I work for now has a similar approach. I showed a personal project and eventually got an offer. It's not even a particularly great one, as I had not worked on it in a couple years.
Short story, they are shooting small plastic cubes with gas inside. The cubes are called "targets".
The "bullet" is fast enough to compress the gas inside the cube, creating fusion.
It works. But in the scenario it does work, a machine is manually opened, loaded, prepared, and then they do the shot. Whole process takes days to prepare.
For it to be viable they need to do this every five seconds.
That is a hard problem to solve. First lights business model is not to solve that problem, but rather producing the "fuel", the tiny cubes with gas inside.
They say there is many details in how they are built which increases efficiency.
But someone still has to figure out how to build a machine that can continuously reload both the fuel and the bullet.
> To deliver this fusion result, First Light used its large two-stage hyper-velocity gas gun to launch a projectile at a target, containing the fusion fuel. The projectile reached a speed of 6.5 km per second before impact. First Light’s highly sophisticated target focuses this impact, with the fuel accelerated to over 70 km per second as it implodes, an increase in velocity achieved through our proprietary advanced target design, making it the fastest moving object on earth at that point.
Conceptually, maybe nothing, but we aren't really talking about your average MG-42 here.
Google+ had circles as well. I found it very hard to properly segment people properly. There are rarely such hard boundaries on relationships. If I'm snowboarding or barbecuing, it's very seldom I only wanna share that with just friends, just family, or just co-workers. It will usually be much more interest-based.
Trying to create interested-based circles was also hard, as the cardinality explodes quite fast (and you're back to square one with not knowing who you share what with).
I guess this is where Snapchat is onto something with giving a very rapid selection of who you want to share with. I usually have a small group of people in mind when I want to share something.
Defining that group, fast, almost on a per share level is the key challenge.
I think the "circles"-approach could be a way, but I think it must be much more dynamic and alive than how Google+ solved it. It must continuously evolve.
Thanks, I get what you're saying here. Often times I find myself adding people to two circles or more. Although there is the option to create new circles I generally recommend keeping close to the existing circles that are created with each account.
On that point we also offer a quick/simple mechanism for sharing to specific contacts. So you're able to share to circles and/or specific contacts.
If you try the app, I would be keen to hear your feedback. Shoot me an email if that is the case.
> Google+ had circles as well. I found it very hard to properly segment people properly. There are rarely such hard boundaries on relationships. If I'm snowboarding or barbecuing, it's very seldom I only wanna share that with just friends, just family, or just co-workers. It will usually be much more interest-based.
Couldn't you make circles of circles in google plus? I remember something like that, I had circles and then grouped them based on interest.
