conor_f
Joined 8 years ago
Karma
234
Submissions
91
Member since
Mar 9
Blog: https://blog.randombits.host
Email: [email protected]
Resume: https://blog.randombits.host/resume/
View on Hacker NewsRecent submissions
Comment · 6 months ago
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?
Comment · 6 months ago
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!
Comment · 1 year ago
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
Comment · 1 year ago
A great point. However it's not a reasonable amount of infrastructure or overhead for many companies or an individual project in my opinion!
Comment · 1 year ago
Here's a quick blog post I wrote about the merit of git worktrees. Any thoughts or feedback let me know!
Comment · 2 years ago
Location: Berlin, Germany
Remote: Preferred
Willing to Relocate: No
Technologies: Python (+ Frameworks), AWS, Linux, Docker, ...
Résumé/CV: https://www.linkedin.com/in/conorjflynn/ | https://blog.randombits.host/resume (PDF Preview)
Email: [email protected]
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.
Comment · 2 years ago
SEEKING WORK | Berlin, Germany | Remote Preferred
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.
Technologies: Python (+ Frameworks), AWS, Docker, Linux, ...
LinkedIn: https://www.linkedin.com/in/conorjflynn/
Résumé: https://blog.randombits.host/resume/ (PDF Preview)
Github: https://github.com/conor-f
Blog: https://blog.randombits.host
Email: [email protected]
Comment · 2 years ago
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:
@ Mar 03 2024 08:00
# Unit: kg
# Bodyweight: 70
Squat:
40 12r
65 8r 2s
40 12r
Assisted Pull Up:
bw-20 12r
bw-5 6r
bw 2r
Highly recommended!
Comment · 3 years ago
How so? What disadvantages does having strings as a first class Type have?
Comment · 3 years ago
Looks super cool! A few questions:
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?
Comment · 3 years ago
1) Some general use cases:
- 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