Def worth getting into, and if you can't secure an Android job, at least you know Java, which isn't going away anytime soon. Def try and have a portfolio of non-trivial apps you could share during the hiring process.
Put the projects on your resume along with the associated impact.
In interviews you'll be asked about them. If you're not mention them or refer to them in your answers to other questions! Discuss your approach to the design of those projects, considerations, performance tradeoffs, how you approached testing, how deployments were handled etc.
Mention the tools you used that made a big difference - maybe swapping compilers led to faster build times and smaller bundles. Swapping test runners led to improved test times. Maybe you tried to swap test runners and that increased test times and so you went back to the previous one. Maybe you led an effort to automate deployments!
Discussing migrations from old patterns to newer ones demonstrates that you know what good tools are available and you know how to leverage them.
Thanks for making this. I think this is a great idea. I've often come across interviews were I had to solve a problem using React and didn't know how to prepare myself for those kind of interviews.
Without changing the architecture in a significant manner/using more training data, there does come a point where adding more parameters will result in no gain (and sometimes even worse results).
There's also a consequence of performance by adding more params. The inference time will be longer and even just training the model will take longer and won't be able to run as many epochs in an efficient manner.
A reason to keep using Electron rather than Tauri is when you need to make sure the UI is going to be displayed the same way on each platform.
Tauri uses the OS's native webview which means that there can be differences in how the DOM is displayed. It's not the same browser engine being used for each platform.
and kudos also belong to the people whove been heavily championing and bikeshedding the proposal on behalf of the rest of us for the last 8 years - which i just discovered is really nicely documented in the repo: https://github.com/tc39/proposal-pipeline-operator/blob/main...
there's usually a ton of nuance behind the syntax considerations and i usually find that the people on tc39 care way more than i do about the things i never think about until its too late. peeking into their discussions is often very enlightening... and a reminder of how hard it is to do language design by committee and at scale.
Last time I wrote an extension (which is a while ago) the changes between the Chrome and Firefox version were minimal. And Edge takes unmodified Chrome extensions.
Obviously depends on the APIs you want, but a typical extension should be trivial to make compatible and package for both Chrome and Firefox.
This _was_ easy the last time I created a new extension, as Firefox also supports the `chrome` namespace for extension APIs, but now that Chrome Web Store isn't accepting new Manifest V2 extensions, you'll at the very least have to have separate manifest files for MV2 and MV3 versions, and different implementations where relevant for MV2 and MV3 (depending on which features your extension needs - e.g. if your extension is really just a way to inject a content script into a page, you might just need separate manifest files).
