Development Setup, 2024
03.26.2024Development Setup, 2024
Notes on what I have been trying to improve lately, and some ideas for things I’d like to see in the future.
My Tools
My tools differ between personal work and professional work. I’ll detail them here, and talk about tradeoffs below.
Professional Work
Professionally, I’m a web/mobile dev contractor. W.e. it pays the bills.
- Editor: VSCode
- Debugger: VSCode when possible, Brave/Chrome/Firefox (in that order)
- Source Control: git, hosted on GitHub
- Frameworks: whatever the client wants. Mostly this ends up being React/ReactNative & Typescript. There’s very little backend consistency.
These things are mostly dictated by team dynamics and client needs. If my entire team uses VSCode, and the codebase is set up with automatic linting rules etc. I’m not going to be the lone wolf off using my own setup. Things are different when you work with a team.
Personal Work
- Editor: 4Coder
- Debugger: RemedyBG (on Windows), some frontend for lldb (VSCode or Xcode)
- Source Control: git, hosted on my own server
- Frameworks: as few as possible. SDL2, libfreetype, stb libs, the modules that ship with the Jai beta.
These are dictated by ease of use and expressive power.
Differences
VSCode is probably the best IDE I’ve ever used. That said, it’s major flaw is that it is an IDE. The fact that I have to Alt+Tab between 4coder and RemedyBG is made up for by the fact that they are both insanely performant, high powered development tools. Meanwhile VSCode can’t keep up with my typing, is a shitty debugger, and the pile of plugins you need to make it usable as a developer means that debugging problems takes an exceedingly long amount of time. All this combines to make it just OK at any of it’s jobs in the best case.
I’d love to move away from lldb as a debugger on MacOS. I’ve learned enough of how to use it at the command line to be functional but it’s just such a bad interface. Xcode is better than VSCode as a frontend, but convincing Xcode it can debug my applications turned into an entire research project.
Moving source control to my own git server has been nice for peace of mind, but hasn’t had much of an impact on me otherwise. I originally did it so I could put a CI runner together for jai (since I can’t put the compiler anywhere public until the beta opens up) but I haven’t gotten around to that part yet.
Projects
I’ve been working on my cross-platform setup lately. The priorities have been:
- Keep up with frequent jai beta updates, while allowing me to overwrite the standard modules with my own fixes.
- Maintain a separate list of modules that are for my projects
- Get 4coder development in a consistent place across Mac and Windows.
- I’ve fixed some keyboard input things on 4coder Mac that have been buggin gme for a long time.
- Make maintaining multiple projects on multiple platforms easy
Future Projects
- increase the editing power of 4coder. I really like the idea of yeet sheets, but find this particular implementation lacking in it’s production readiness (no shade to the dev, just not ready for me to use).
- non-manual versions of this would be really useful, such as always having the right panel be an editable yeet sheet of the types/sub-function calls/call sites of the code you see in the left panel. Memory management for this sheet would be pretty intense.
- cross platform CI runner for jai
- ship a god damned game
Future Wishes
These are wishes for work I’m hoping other people do. Obviously they are very busy and should just take this as encouragement that I really like their work and want them to keep going.
- I’m really hoping the Dwarf/Linux version of RadDebugger come out soon. Doing my own Mac port wouldn’t be too much of an effort after that, and having a real debugger on Mac would be a dream come true for me.