This is a perfect example that I've often seen in practice. There's nothing blocking in this workflow at all, and no reason these changes cannot be made in independent changes. e.g.
1) API implementation - Including tests and docs this should be perfectly acceptable to merge and review independently
2) UX implementation - Feature flagged, dummy API responses, easy to merge + review
3) One quick "glue" PR where the feature can be integration tested etc
This prevents awful merge conflicts, multiple rounds of increasingly complex stacked reviews, and a host of other annoyances.
Is there any reason that the stacked PR workflow is better that I'm ignoring or overlooking?
This just reeks to me of bad practice. Why use this as opposed to breaking your change into smaller PRs and merging them individually behind a feature flag or similar? With this, you have a marginally better UX for reviewing through the Github website, but the underlying issues are the same. The change being introduced is not sufficiently testable by itself, or it's (somehow) too tightly coupled to other parts of the UI/codebase that it can't be split. You still need to test for integration issues at every point of the stack, and some architecture issues or points of code reuse can't be seen from stacked changes like this.
Not for me, but I'm glad it fits other people's workflows. I just hope it doesn't encourage people to try make poorly reasoned changes!
Super interesting, thanks! I didn't think about how this issue could easily point to a major improvement that could be made on the package manager level. Unfortunate that in Python land only Conda supports it though. It looks from the docs that uv may also support it? https://docs.astral.sh/uv/concepts/cache/#cache-directory
Hey, I'm Conor, a software engineer specializing in the backend, but capable of using whatever technologies required to get a problem solved. I have experience with large multinationals, but much prefer my time working with startups. I was the first hire in my current company, and am now looking for a new opportunity having helped the company find product/market fit, scale the solution, and reach a position of stability. Most of my details can be found on my LinkedIn, including links to my Github, Blog, and other technical works.
I am a software engineer specializing in Python backends, but have demonstrated ability using whatever technology necessary to best solve the problem at hand. I have experience working with large multinationals, and startups, both in person and on a remote-only basis. My current role is fully remote, and involves software architecture/design decisions, PoC prototyping, DevOps, improving developer tooling, and general purpose programming.
The best place to see my professional experience is on LinkedIn, but feel free to reach out to me by any means you prefer so we can discuss opportunities.
Another interesting thing in this space is Traindown[1]. It's simply Markdown for your exercises. As an example for those who need convincing to go to a link, this could be a simple workout:
It's much more free-form than this, which is a bonus for me and allows me to track metadata such as weight, time of day I'm exercising at, or general mood/feeling about the workout. I can ultimately just take these plain markdown files from the app (I use a basic Android app that visualizes this Markdown[2]), import them and do whatever processing I like in Python.
1) Can you get the actual code output or will this end up calling OpenAI each function call?
2) What latency does it add? What about token usage?
3) Is the functionality deterministic?
- Getting familiar with new APIs
- Bouncing general knowledge questions off it
- Having "discussions" to interact with it in a Socratic style
- Giving some "personality" to automated services by calling it as an API
2) Thanks for the pointers! Will check them out today!
I don't have much interest in playing with the internals for now, but I generally like keeping my data personal and the services I use self-maintainable as much as reasonably possible! I also feel like I could find the token limits and price limiting with ChatGPT.
Try to write monthly about technical projects I've managed to complete. I'm beginning to mix it up to include more recently musings on non-technical topics now however!
1) Have you considered how this could be made more mobile friendly? Most places I could see myself using a device like this, I wouldn't have access to WiFi. Is there an equivalent of a USB SIM card adapter that would fit here?
2) What sort of battery life can be achieved with this?
Looks great though! Am very likely to order an iteration of this :)
My ISP wanted me to pay ten euro per month for a static IPv4 address, so I set up a DIY Dynamic DNS system as I didn't want to use yet another external resource/tool.
Let me know about any improvements I could make and how I can improve my writing as I want to keep writing more blog posts in the future.
Has elementary improved from when I last used it a few years ago? Felt like a standard arch install configured nicely. Things looked great but broke frequently.
I've heard mixed things about ZorinOS including things being less-than-open and fragile too?
1) API implementation - Including tests and docs this should be perfectly acceptable to merge and review independently 2) UX implementation - Feature flagged, dummy API responses, easy to merge + review 3) One quick "glue" PR where the feature can be integration tested etc
This prevents awful merge conflicts, multiple rounds of increasingly complex stacked reviews, and a host of other annoyances.
Is there any reason that the stacked PR workflow is better that I'm ignoring or overlooking?