I know about the indexing, marking directories correctly so as not to trigger reindexing etc etc.
Since i work on a couple dozen services in a monorepo in a few languages, no amount of heap memory or CPU will be enough.
One days its the grapqhl plugin, the next day its typescript type inferrence, then something with rust, it just never stops. Sometimes even the golang operations are slow.
Its all just monorepo issues, but i expect my IDE to be able to handle a monorepo, all other IDEs work without issue (and are inferior in functionality sadly)
I have given it up to 30GB of heap and i tried many different GC configs, i even ran it and my project on ramdisk.
The issue is related to using a monorepo with lots of code in different languages - openening single folders is fine. Ut i want to be able to work on dozens of services in a single window, all other editors manage just fine
Last week i cancelled my Jetbrains sub after a decade of daily driving it. I just cant take the performance issues anymore. Across 5 different machines all kinds of actions would just take ages and it got worse every year.
Moving to Apple Silicon made it bearable for a few months but somehow Jetbrains manages to get slow even on a M3 Max with 36GB RAM.
Ive been fiddling with configs for years, i tried everything since i was a Jetbrains diehard.
Instead of trying to catch up to other AI editor they should get back to their core and make it possible to use Jetbrains on medium sized Monorepos with multiple languages.
I was hyped when i heard they would release a standalone git product, but then they scrapped it!
In the end i was only dependent on it for debugging and my usual git workflow.
I now switched to zed and gitkraken, i will figure out a new debugging workflow, ill never wait 5 minutes for a simple search action again
I guess having a new up migration to cover the case is better, but its nice to have a documented way of rolling back (which would be the down migration) - without applying it programmatically. But it helps if other team members can see how a change should be rolled back ideally.
I wish they would limit the number of attendees somehow or have some way to manage overcrowding.
In 7 attendances i and most people in my group got a cold or the flu (this was before covid) - 7 years in a row.
The slack notification noise triggered me to check Slack frantically in case i was mentioned, but there was nothing. Slack really has us conditioned well.
A bit over a year ago I lost a dear friend, while his girlfriend was pregnant.
The feeling of seeing something the person will never use again is soul wrenching. I wept when I read the line "No salt. No salt means that he’s not cooking. He’ll never cook again."
The child is a ray of light for me whenever I see it, I hope the family can find a little comfort in this piece of him that will be brought into the world.
I have followed this story for a while now and wish the family a brighter path in the future. Thank you for focussing my thoughts on what is important, instead of the daily tech grind.
* The main thing that makes ChatGPTs ui useful to me is the ability to change any of my prompts in the conversation & it will then go back to that part of the converation and regenerate, while removing the rest of the conversation after that point.
Such a chat ui is not usable for me without this feature.
* The feedback button does nothing for me, just changes focus to chrome.
* The LLaVA model tells me that it can not generate images since it is a text based AI model. My prompts were "Generate an image of ..."
I dont understand how this is better than a docker-compose.yml with your dependencies, which plays nicer with all other tooling.
Especially if there are complex dependencies between required containers it seems to be pretty weak in comparison. But i also only used it like 5 years ago, so maybe things are significantly better now.
I just never could be happy with a TV without an OLED panel after i got my first one last year. Since then all other screen types look like garbage to my eyes, the better cinema projectors too.
Shouldn't have bought an expensive big monitor for work without OLED the year before, but i hear that OLED is not that great for close up text rendering.
Maybe someone knows how to solve a common sharing issue, I didn't see it mentioned here:
I have a single ultra wide screen and would like to share a virtual area that has a normal size (16:9) with people via Google Meets, Slack, etc. Otherwise I have to share a window, stop, share another one etc.
Really bad, especially during some on call emergency session.
So far I couldn't make it work, only Zoom had this feature at some point but nobody uses Zoom where I have worked.
Dont take this the wrong way, but this is the answer i would get from enterprise devs usually when pointing this out.
Then i would realize that their definition of a real issue was completely removed from any business or user impact, but geared more towards their understanding of the process detail in question.
I would argue that there certainly are some good places for unit tests, like if you have some domain-driven design going and can have well defined unit-tests for your business logic, but this usually is the smallest part of the codebase.
Mocking things that talk to databases etc. usually gives a false sense of security while that thing could break for a whole number of reasons in the real world. So just dropping the mock here and testing the whole stack of the application can really do wonders here in my experience.
Using mockserver etc. you can cover for these things in component-test cases even more easily through your whole application while being more flexible with bigger code changes than unit tests allow.
So at work we would run tons of tests against the real service with a real database, seeding thousands of schemas to allow for parallel testing of tests that change state.
This takes 3 minutes, 1 if you use tmpfs.
It only takes <10 seconds if you dont run writing tests.
These actually cover most real world use cases for a query-engine we maintain.
Unit tests have their place for pieces of code that run based on a well defined spec, but all in all this integration or component-level testing is really what brings me the most value always.