Looks like my Lemmy-client of choice did some retrying when I had poor connection, sorry about that.
I think trying to go cheap on native apps was always kind of a fool’s errand, tbh. Cordova, Xamarin, React Native and so on - all pretty sub-par solutions leading to poor experience without actually materializing the desired savings.
Looks like my Lemmy-client of choice did some retrying when I had poor connection, sorry about that.
I think trying to go cheap on native apps was always kind of a fool’s errand, tbh. Cordova, Xamarin, React Native and so on - all pretty sub-par solutions leading to poor experience without actually materializing the desired savings.
Looks like my Lemmy-client of choice did some retrying when I had poor connection, sorry about that.
I think trying to go cheap on native apps was always kind of a fool’s errand, tbh. Cordova, Xamarin, React Native and so on - all pretty sub-par solutions leading to poor experience without actually materializing the desired savings.
Looks like my Lemmy-client of choice did some retrying when I had poor connection, sorry about that.
I think trying to go cheap on native apps was always kind of a fool’s errand, tbh. Cordova, Xamarin, React Native and so on - all pretty sub-par solutions leading to poor experience without actually materializing the desired savings.
If you’re prioritizing cost, you should probably already be building a web application imo. There’s very few cases where I would recommend cheaping out and building a native app, it’s just kind of unsound.
If you’re prioritizing cost, you should probably already be building a web application imo. There’s very few cases where I would recommend cheaping out and building a native app, it’s just kind of unsound.
If you’re prioritizing cost, you should probably already be building a web application imo. There’s very few cases where I would recommend cheaping out and building a native app, it’s just kind of unsound.
If you’re prioritizing cost, you should probably already be building a web application imo. There’s very few cases where I would recommend cheaping out and building a native app, it’s just kind of unsound.
If you’re prioritizing cost, you should probably already be building a web application imo. There’s very few cases where I would recommend cheaping out and building a native app, it’s just kind of unsound.
If you’re prioritizing cost, you should probably already be building a web application imo. There’s very few cases where I would recommend cheaping out and building a native app, it’s just kind of unsound.
Are we looking at Manna becoming a reality? https://marshallbrain.com/manna1
It’s mostly stopping the world to re-write everything from scratch that is a mistake.
Good practice is to refactor the codebase until it’s modular (if it’s not already sufficiently modular), and then proceed to replace modules gradually until you reach your desired state of re-writtenness.
This has the benefits of actually getting you up to speed with maintenance over time without having to halt new feature development, giving you the best of both worlds.
Absolutely. I think it helps a lot to understand the mechanics of git and rebasing, but after a few times it just makes more sense than merging, really.
Nasty thing to say on account of the author of the article being the OP as well.
The fact that you have to kind of understand how git works under the hood to really unlock its full potential is a definite design flaw of the tool, but given its ubiquitous use in our industry, I encourage you to check out how git works under the hood. Once you learn the underlying concepts, you reach a whole new level of proficiency with git, no longer having to just get by, and instead you get to thrive.
I disagree wholeheartedly with this. I consider the commit history as documentation for pull requests and for future history, and as such I make liberal use of interactive rebasing to curate my commits.
Rebasing in general is one of those things that I picked up fairly late, but now it’s essential to my git workflow.
So you’re probably not going to be able to swing getting a project greenlit to test everything on your frontend, partly because your management seems a bit stingy, and partly because it’s probably not the best approach to do this kind of thing anyway.
To the claim of that you can’t test UI: only if you’re not creative enough. Behavior can 100% be tested, and is worthwhile to test, while UI looks can be verified with screenshot tests.
How I would probably approach this would be:
Following these steps should successively put the codebase into a healthier state.
Another perhaps even more valid option would be to look for a better job - working in headwind from management is not recommended, as it will deteriorate your mental health.
Good luck!
I remember my first job working with C# - this was the common sentiment: it’s a Java that is better than Java at being Java. I mostly agree with that.
Try using Kotlin some day, though. I consider that language to be even better than C#, and it additionally gets to leverage the JVM ecosystem.
Kotlin > C# > Java, in my book
Weird thing to gatekeep.
You can use Hidden for this - https://github.com/dwarvesf/hidden