I'm slowly building an IDE with mentor/skill-level awareness baked in.
I've noticed that juniors and new hires often fall into an impostor-syndrome trap when reading an unfamiliar codebase or reviewing a senior peer's PR. Documentation helps, but it usually runs into the curse of knowledge: it's written by someone who's spent so much time in the code that they've lost sight of what it's like to be new to it.
I've always liked the rubber-ducking process, and mob programming too, so I'm trying to combine both into a modern AI-enhanced form:
- "Duckies" with distinct personalities (really, skills) that each specialize in a particular kind of problem
- "Teachable moments" (working title): small bubbles that surface something novel, tangential, or foundational as you work
- Skill-level detection and a routing model, so the app doesn't overwhelm or annoy you with explanations you don't need
Each duck also runs on a tiered memory model, rather than one flat context window. There's a core memory, essentially the duck's resume, defining what it's actually skilled at. Above that sits a longer-term memory for company standards and code style, and a separate long-term memory scoped to the project itself. Short-term memory then covers whatever task or feature is currently in flight. The idea is that a duck should reason more like a team member with a real employment history than a chatbot that forgets everything between sessions.
It's called Duckies AI (https://www.duckiesai.com). It’s very rough, working locally, but not in a state I’m ready to ship yet. I'm hoping to ship an alpha soon. Turns out there are a LOT of table-stakes features an IDE needs.
I love this. I have been building and IDE for myself. My non-technical team wants to use it after using lovable and things like that. I started building a dialect of JavaScript to make more approachable but that seems impossible the more I get into it.
I started down this path, although with a VS Code plugin, but I didn’t find the ability to visually tie into the text editor with chat modals/bubbles. It’s likely what I would pivot to if I don’t like the amount of effort necessary to build the basics.
This will sound like cheating but I argue for the time it saves me, both in creation and on-going maintenance, and delivering a quality finished project: Squarespace.
The clients are happy, if they get to the point where they want to manage the content themselves, and for less than $300/yr they get hosting, access to a payment processor if they need it, and domain renewal. It's been a no-brainer.
I don't feel that's cheating. In many ways you're a better option than a generalist, since I assume you've become an expert on that platform. I know others who focus on Shopify, Wix, etc.
I do same, but with Wordpress and Elementor builder. It's good enough for most small scale clients on nano-size budget. But Squarespace is a solid tool too!
Will they make a couple more $ out of this? Maybe.
I suspect they'd rather not have a proliferation of developers farming out their profiles and dealing with it on the service/support side. Developers with pseudo-ownership of strangers devices and users who don't fully understand what they are agreeing to with tying their device to a unknown developer can't be fun.
The article is fascinating but one thing I am finding very common on these engineering blogs is no easy path back to the company or service. Understandably the logo at the top goes back to the blog homepage and the copyright at the bottom is just static text.
I could search or visit one of the social pages linked to in the footer but it seem like an obvious link one would want to have.
Hitting the “Join The Team” button up top takes you back to the main site, which seems reasonable since in most cases a technical blog is meant to be a recruitment funnel more than a general public-facing PR document, no?
So although there might be “waste”, emergency preparedness shouldn’t be forgotten about. It’s safer and better to have blood available when it’s needed than to be begging for it.
What I think they're saying is that with Adblockers, they can phone home which ads they block, URLs they see, etc.
Content blockers impose rules at the outset and the rule generator won't see what the URLs/content actually is.
The way I would think of it would be like "let me see what you're seeing and I'll let you know what to let through" vs "here are a list of things you shouldn't let through but I don't need to know about what the hit rate actually is".
Although I could be misunderstanding the implementation.
While true with some, I believe uBO is a list implemented client-side, right? Other ad-blockers can and do phone home and let through ads that have paid, but uBO just has the EasyList filter installed locally and blocks those URLs. That was my impression at least, I never personally went through the source code.
I trust uBO and roughly zero others. In fact, uBO has to remind people at every opportunity to avoid certain others. It is all the others, now and in the future, that are prompting Apple to do this, and the one well-behaved extension is unfortunately suffering as a result.
I mourn the loss of uBO, but I'll take that tradeoff knowing that I can relax knowing that my family and friends aren't going to end up using some intrusive nightmare of an "ad-blocker" with Safari.
This is exactly it. Even if a malicious extension gets through, they have access to nothing on the user side. It's not a fair trade off but, in my opinion, it is a worthwhile one.
> That was my impression at least, I never personally went through the source code.
That's the rub though. There's nothing but trust preventing them from including some spyware in the next automatic update. Actually not even trust, whoever has account access to publish for uBlock could have their account hacked and someone malicious could inject spyware into a version of the extension.
Trust is everywhere in computer security. You trust Google to not deliver a backdoored version of Chrome to your machine when you download a binary instead of building from source. You trust them to not break the law and leak your personal data to third parties or discriminate against you based on the content of your emails.
This isn't as much about what existing extensions do today but all about what potential extension could be doing tomorrow.
If an extension doesn't get full access to all the pages you are reading, it can't do bad things with that access when the extension's owner inevitably changes (see the fight between uBlock and uBlock Origin for example) and spyware features are added.
Even if it is, it doesn’t matter. The problem Apple faces is how to prevent the other bad actors from abusing their API. The answer they’ve settled on is remove those capabilities from the API. Another answer would be to leave the capabilities but somehow only grant access to them to “trusted” parties.
I’m sure that would have gone over really well, too. /s
In the later scenarios, what assurance does the Ablocker have that their requests are respected? I could easily see a scenario where an Adblocker says "Hey Chrome block all requests to ads.google.com" and Chrome saying "Sure thing buddy" then completely ignoring that request.
There's really nothing at all preventing Chrome from doing that today if they wished... they can manipulate the page before and after the Adblocker sees it.
And then what? Google will say that it's protecting critical functions from breaking and to piss off. Suddenly Google is a monopoly in the ad space because they have the predominant browser and let through only their ads.
they arguably are effectively a monopoly now. Them doing things like this isn't remotely new. They just got caught tracking everyone's smart TV usage. Nothing will happen to them until:
1) the Government decides to intervene.
2) Users give up and start using different services.
I'm pushing for #2, but then I switched off like a decade ago, when I saw the writing on the wall.
Adblocker apps/extensions don't require that assurance. The user requires this assurance, and if the browser ignores the user's wishes, the browser is the application that should be held accountable by users.
How is the user to know if it's the AdBlocker or the Browser though? It's a he-said-she-said kind of situation with the AdBlocker and the Browser potentially pointing the finger at each other.
This setup gives the Browser/Maker plausible deniability when they act badly.
- Random scratch files in ~/Desktop/Rug (purged monthly, no backup)
- All development in ~/Workspace (routinely backed up)
- Source controlled development in ~/Workspace/Repos/[entity]/[project name] (excluded from backups)
- All non-SCed files in ~/Workspace/[entity]/[project name]
- Downloads in ~/Downloads (purged daily of older than two weeks, not backed up)
- Personal computer has ~/Workspace symlinked from a Dropbox folder: ~/Dropbox/Bryan/Workspace
- Family photos in ~/Dropbox/Family/Photos/[year]/[month]/[YYYY-MM-DD HH-MM-SS].[format]
(routinely push-only sync to Amazon Glacier)
* Several cron jobs to help maintain everything
* Several custom Zsh plugins to make jumping around in shell a breeze
* Daily bullet journal+markdown style notes auto source controlled in
~/Workspace/Repos/Personal/eod/[year]/[month]/[day].md
I've noticed that juniors and new hires often fall into an impostor-syndrome trap when reading an unfamiliar codebase or reviewing a senior peer's PR. Documentation helps, but it usually runs into the curse of knowledge: it's written by someone who's spent so much time in the code that they've lost sight of what it's like to be new to it.
I've always liked the rubber-ducking process, and mob programming too, so I'm trying to combine both into a modern AI-enhanced form:
- "Duckies" with distinct personalities (really, skills) that each specialize in a particular kind of problem
- "Teachable moments" (working title): small bubbles that surface something novel, tangential, or foundational as you work
- Skill-level detection and a routing model, so the app doesn't overwhelm or annoy you with explanations you don't need
Each duck also runs on a tiered memory model, rather than one flat context window. There's a core memory, essentially the duck's resume, defining what it's actually skilled at. Above that sits a longer-term memory for company standards and code style, and a separate long-term memory scoped to the project itself. Short-term memory then covers whatever task or feature is currently in flight. The idea is that a duck should reason more like a team member with a real employment history than a chatbot that forgets everything between sessions.
It's called Duckies AI (https://www.duckiesai.com). It’s very rough, working locally, but not in a state I’m ready to ship yet. I'm hoping to ship an alpha soon. Turns out there are a LOT of table-stakes features an IDE needs.