mrdonbrown

Gotcha. What would the ideal look like? Someone could create a financial doc they want to share then tell their agent to "Share foo.md with my team", and it would via mcp? On the backend, that mcp server takes the file and packages it into the plugin, which hopefully auto-updates?

Makes sense. Would a tool that let non-tech people easily share and distribute skills without needing git be worth adoption? Would the info being shared just be skills or something else?

This is an underrated comment. You could have the best product out there, but AI has not only lowered the effort for competitors but has flooded traditional ways to get your product known, from outbound sales to content marketing. Sometimes make you question whether there are customers anymore.

Why stop at skills though? If you are trying to solve the provisioning problem for agent tools, shouldn't that also include MCP, commands, hooks, rules, etc in addition to skills?

I could be wrong, but I don't think there is anything in the skills spec that prohibits a skill from having binaries? A skill may even choose to embed them to be able to run in sandboxed environments.

Agreed on skills not being static. Of course, with the way the internet works, I don't want them to be too dynamic either :)

If you want to share skills using something that has versioning, automatic updates, and focused on teams vs the internet at large, consider sx - https://github.com/sleuth-io/sx

If you want to share skills (and other tools) with teams at scale, consider sx - https://github.com/sleuth-io/sx

[yup, my project :)]

I have a CD copy of the game, and many fond memories playing it with the wife in the early 2000's...

Right, Jira is great at planning, but requires a lot of gardening to keep it up to date with actuals like when things ship and where. Glue automations like this can be really helpful.

I met and worked with Bob in open source work in the mid 2000's, mostly with what would become Guice. He wrote this framework, again, thanks to his distaste of Spring and we put an early version of it what would become Apache Struts 2. Man, if I ever got cocky in my programming skills, I just needed to read that Guice prototype code and I was quickly humbled. The best part is he was just an awesome guy to be around. Very friendly, accepting, humble, and a ton of fun. I still talk about this guy I know who was married on the bridge of the Star Trek Enterprise 1701 D (at the MGM before it was torn down)...

I tried and liked Mint, but ended up with Red Pocket (MVNO that does Verizon, T-Mobile, and AT&T) when I moved somewhere that needed AT&T. It is pretty handy having one provider but having a choice of network. It also helps they have plans as low as $5/month, which is great for kids and infrequent users.

Where I found that fell down was wanting to do things like slow zooms and interesting transitions. I'd love something like a Python or bash script to tweak that addressed those.

Shotcut has this one cool feature [1] - drop a bunch of pictures into it and it'll create an animated slide show automatically. I've looked for ways to automate that via something like ffmpeg, but haven't found any better options.

[1] https://forum.shotcut.org/t/slideshow-generator/19162

I haven't tried using the teleprompter with a webcam, but I don't see why it wouldn't work. I use a Sony a6600 myself, with a Sigma 16mm/f1.4 prime lense.

Regardless, I recommend capturing in 4k, and running that through OBS so you can zoom/crop the image for ideal framing, optional of course.

Sure, this is what I see [1] and you can see how it looks on the other side from my Twitch streams [2]

[1] https://i.imgur.com/4JPIHx1.jpg [2] https://www.twitch.tv/mrdonbrown

I use the Caddie Buddy one [1], which is a bit more robust for bigger cameras. There are other options where you can use your phone or something, but I prefer using a mirrorless and a good sized monitor.

[1] https://caddiebuddy.com/teleprompter-for-ipads-androids-and-...

I'm surprised no one has mentioned using a teleprompter yet. You can pick one up for around $100 and when combined with a little 7" monitor (another $100) attached to your computer, creates a nice setup for zoom calls where you can look directly at your partner. Also doubles as a great talking head setup for video production.

Exactly! Faster cycles means less waste and more productivity, not to mention better solutions and happier team members. It takes work for sure to build those relationships, but everyone is better off for them.

Well said. Funny we realized long ago that you can't just have a backend team build an API then throw that the wall to a frontend team to use it, yet somehow, we often try to do that with design. To achieve what you describe takes more than a conversation, but a healthy and active relationship.

I recently did an interview on this topic [1] and I was surprised to hear the designer say, "If the developer tells me to design whatever and they'll build it, that is a huge fail". I kinda assumed designers were in their own world where we (developers) met at the DMZ, but his point is we are all part of the same team. The more I thought about it, the more sense it made.

[1] https://www.youtube.com/watch?v=0Oi913i2mCA

When I worked at Atlassian, we had this issue as well, given all the many services that were deployed for products. A few of us left and created Sleuth [1] to solve it for Atlassian and folks like you. Sleuth helps you know what is deployed, its health, and helps with workflow automation. It also tracks the DORA metrics so you know how healthy a service release processes is.

[1] https://sleuth.io

I built exactly this in my Manim-based library, code-video-generator [1] (via the code-video-generator command and the --slides flag). It basically turns any Manim scene.wait() call into a pause that I can then advance with a clicker. I used it for this video [2], where I was recording in front of a green screen, but wanted the exact control when the animation continued. code-video-generator played the video fullscreen, which I then captured via obs [3] and used the obs display as a monitor to see if I was pointing at the right spot. Was a bit tricky to get all set up but worked pretty well.

[1] https://github.com/sleuth-io/code-video-generator [2] https://youtu.be/e21hJnB9J5k?t=44 [3] https://obsproject.com/

The library should work with a few other languages like Java, JavaScript, and C++. If you want to add another one, take a look at comment_parser.py as it is pretty simple.

Related, if you want to create a code walkthrough video, I wrote code-video-generator [1]

It uses Manim [2], an animation library commonly used by Math teachers, and adapted it to code walkthroughs. Just comment code as you do and it generates a video for it. I've been using it to generate visuals for youtube videos [3] with some success.

[1] https://github.com/sleuth-io/code-video-generator [2] https://github.com/manimcommunity/manim [3] https://www.youtube.com/watch?v=e21hJnB9J5k&t=2s

My team recently put in automation so that we use CircleCI for the staging deployment, have it wait for manual approval, then deploy to production. However, we can also give the Slack staging deployment message a +1 reaction, which will automatically approve the production deployment for CircleCI. This way, we get an easy dev UX but all the CI features of CircleCI.

Right, got it. I think it is the lag time involved in the pipeline. Once a developer clicks merge, CI has to run, an artifact has to be created and uploaded, then usually a deployment to dev or staging is kicked off. That takes somewhere between 5 minutes and 2 hours in my research. Then, once done, the dev can click a button to push to prod, though often that is just to a canary, so another 5-30 minutes, then repeated for other prod environments. That whole process takes a lot of babysitting, and realistically, the dev has started on another task and forgot about it, making it take even longer.

By making it automated, the dev can immediately start on a new task and the deployment can go out quicker, meaning the next dev can start on their deployment. Therefore, I see it as helping preventing costly context switching and therefore, improving efficiency.

To me, the main value of CD is ownership. The developer can own a change from beginning to end, and most importantly, its impact on production. That feedback loop creates better future changes and a better developer.

Automatic deployment takes it to the next level where it becomes so easy to deploy that the dev starts fixing things they would have previously ignored because it was too painful, annoying, or time consuming to deploy before. A typo here, a refactoring there, and now they can fix, push, and go back to what they were doing within minutes, but do so with the confidence they won't break things. It is kinda like the difference from when CI takes 3 minutes to 10 minutes. It isn't much but that longer time means you alt-tab over to reddit or whatever, forget what you are doing, and now that task takes orders of magnitude more of wall clock time.

As my startup [1] is in the domain of CI/CD, I've been doing a bunch of customer development interviews to better understand how teams deliver software. I was also surprised how few teams use full Continuous Delivery, even at cutting edge tech companies. It is indeed often used by small teams, even within large companies, where they deliver internal backend services.

The most common seems to be auto-deployed to staging or a dev environment, with some sort of daily or weekly process for promoting to production. One company built a Slack-based approval process using +1 or -1 reactions, and another has a zoom meeting where every author has to attend and is walked through a checklist before the release is approved.

My team also had a manual approval step to production, which theoretically meant the dev would check logs, dashboards, and alerts before approving, but in practice both with us and teams I talked to, that is followed about 50%-80% of the time.

What we built into our product, Sleuth [1], is a way to automatically promote staging releases when the staging release was determined to be healthy and soaked for a minimum amount of time. This allows the 80% case to simply flow through to prod without developer babysitting, whereas we can easily interrupt the process with a -1 reaction in Slack if it needs more manual testing. I think this is the ideal - the common case is the code flows but you still have an easy way to interrupt the process when the change needs it.

[1] https://sleuth.io

Video creation and editing [1]. I used to speak at tech conferences but after taking a long break, I wanted to get back into some form of instructional content. My kids are obsessed with YouTube, and I started a new startup, so I figured I'd give it a go. As for how I learned, well, doing it, and of course, watching YouTube videos.

[1] https://www.youtube.com/channel/UCmIIOHKgJnGQruIVD_Zx71g

I'm surprised tawk.to [1] hasn't got a mention yet. It was easy to set up and while quite limited, is free so perfect for our small startup.

[1] https://www.tawk.to/