Thank you for this repo! I had actually just started on building my personal MCP server over the weekend but hadn't gotten too far. Definitely going to check out the repo to see if my initial setup was off base at all.
I just wanted to say thank you for these replies. I was also confused by the top of this comment chain as I think that author misunderstood what the point of this project this. I wanted to jump in and say something to the effect of "The OP (Jake) has clearly shown he has the aptitude to accomplish tasks by building this tool" but you've done that far better than I could have. Thanks again.
I was trying to find a way to thank xpe more privately but this is evidence I should just go ahead and do it. So, thank you too.
Thanks xpe, I appreciate you jumping in here. I was struggling to find the words here and I think you did a wonderful job both championing the intent of the post as well as articulating why I found it difficult to engage. You've given me tools to use going forward.
A problem I just ran into with this is that squash and merge obviously loses all the history of the merged branch. If you branched off that branch, when attempting to rebase main, there are a lot of conflicts because all that history is gone. A co-worker suggested cherry-picking commits from the second branch off a clean main as an approach to not dealing with all the conflicts.
Example:
main -> Branch A -> Lots of commits on A -> Branch B -> Lots of commits on B
Now we squash and merge A into main. B now has all of A's commit history, plus some of its own, instead of just it's own. Rebasing main in causes a lot of conflicts.
IMO the best is to merge main into your branch. Then squash the result into a single change and rebase onto main. This way you can merge in a "normal" way, removing the conflicts with main, but then your own change goes in cleanly on top of main.
It takes some git gymnastics to transplant the merge back onto main cleanly.
My last round of interview all stemmed from posting on the Who Wants to be Hired thread. I examined a few months of previous posts and looked for descriptions people had written that stood out and looked good. I went back and looked at a previous month I had posted and noticed that post by me didn't stand out. I added a well written prompt about what I was looking in an organization and a role and I feel like that helped to give color to who I was compared to a giant list of technologies I'm capable of working with.
I also received feedback from people who reached out that they went and read my personal website / blog; that gave them better insight into who I was. Don't underestimate the fact that soft skills and communication go a long way in the interview process and software engineering as a whole. Having a blog, which demonstrates the ability the communicate over a written medium, I feel is a great way help yourself stand out. It isn't a requirement to land a job, but I think it helps.
> I've fully focussed on the second approach. As a consequence, each article takes a lot of time to complete, so I generally don't finish more than one per month.
This is what I've been running into. My approach comes out of writing a bunch of code or re-writing the same sort of code across multiple projects and realizing it would be useful to share. Next I'll dump all the code into a blog post and have to start formulating what the structure of the post will be. What content do I need to add to support my claims that this code is correct (or correct enough to use)? Add in time to research alternative approaches to the code, research and write about the alternatives.
I've found that I'm proud of my finished articles but it takes awhile to get them written. I'm in the midst of one that I've kind of hit a writers block on because I have a fair bit of research left to do. I haven't been motivated to do the research and write up the findings. However, I feel like thats normal and I'll get back to it at some point.
"For Ractors to be viable to run a full-on application in, Ruby would need to provide at least a few basic data structures that would be shareable across ractors, so that we can implement useful constructs like connection pools.
Perhaps some Ractor::Queue, maybe even some Ractor::ConcurrentMap, and more importantly, C extensions would need to be able to make their types movable."
Which we see in Mike's library he has started work on a Queue and a Map.
I haven't fully wrapped my head around all the nuances to using Ractors nor have I tried to do anything with them yet. But its encouraging to see the discussion around them ramping up
Full-stack is an overloaded term, but it used to mean "a completr solution for building a web app."
From the comment above: Next.js is the opposite of a "batteries included" framework. No abstractions for ORM, background jobs, sending emails, managing attachments, web socket communication - all very basic stuff when dealing with a production application.
Well, if you went so far as to reimplement Next.js, I don't think you're using Rails either.
And frankly I'd like to see it since that's a really hard problem to just roll your own solution. And probably a huge waste of time if you're trying to ship a real product on top of it.
Combination of giving back and trying to give insight into myself as an engineer.
On giving back - Throughout my career I've read tons of blog posts that have given me the information I needed to get started or un-stuck on a task. I hope when I write about things that someone out there may wonder 'how do I X?' and my blog post shows up when googling.
On giving insight into myself - I've had people reach out while I was doing a job search that said they looked over my blog posts and that gave them a positive signal which led them to reach out to me for a position.
reply