royosherove

Working on full stack prototyping agents that own their own Aws account (zero deploy friction). Think speed of lovable/ base44 with power of Aws services

https://github.com/inceptionstack/lowkey

TLDR: A startup called LymeAlert is launching a $40 at-home test (August 2026) that tells you in 15 minutes whether a tick carries Lyme disease. You grind the tick in a container, insert a chemical strip, and it changes color if Lyme bacteria are present. Founded by an MIT Sloan MBA / physician assistant who wanted to save people the $50–$450 and week-long wait of lab testing. Caveat: it only detects Lyme (not other tick-borne infections like Alpha-gal), though a multi-pathogen version is planned for next year. They're also building a smartphone app to crowdsource infected-tick locations.

Ah I was missing the WANDB_RUN env var. so did not get any logs. thanks!

Cool. Is there a simple "howto" on running this repo with training on W&B for a programmer like me who has never done model training flows? Maybe you could share the steps you took?

Hey saaaaaam . I'd love to pick your brains a bit on this. I'm working on a web3 protocol ("Legato") relating to many of these issues. Any way we can connect? (I can't find a way to DM you on HN). roy at osherove .dot [com]

Open Source Blockchain music registration & Royalties: I'm a fullstack dev working on a blockchain project (eth/polygon) for music registration and royalties on chain. Would love to work with anyone with web3 backend(solidity) / frontend(react) experience, that is passionate about disrupting the music industry - for now it will just be a big open source permissionless project. But it could end up being a nice startup with many hooks to use for profit on top: from distribution to integrations - it's a blue ocean. (email in my profile)

should be slightly better now... at least not horrible.

Crap. I'm still working on the mobile version - sorry about that.

I believe we need to stop, as developers, to contribute our expertise to enabling such blatant surveillance that hurts much more than it helps. We're ruining our own and our children's future by writing the code that enables this, by teaching people how to write such code, how to test such code, how to deliver such code. It's on us.

"There are many things I am not. I am not a cat..." - Keith Gill

I'll add after 20+ years: - Being able to communicate ideas > Being a great technical developer - For every great developer that's an asshole, you can find a great developer that won't be an asshole. Don't keep assholes. Google the "no asshole rule". - Making the team feel safe to discuss stuff they don't know freely and ask questions that might seem stupid in other teams makes for a great team that's not afraid to challenge assumptions and break through with new skills. - TDD is a skill just like refactoring. Learn when it makes sense. - 80% of architects in enterprise don't have the skills needed from them. including the things stated above. - Learning the Theory of Constraints and applying it to find bottlenecks in the process, pipelines and structures of your teams/projects is one of the most useful things you can apply to become more productive. - Learning what to measure and what not to measure, lagging vs leading indicators can help you communicate to management about what changes truly need to happen to make your team work more effectively. - Whiteboards (and remotely, miro boards) are very effective and can be used for easily 50% of meetings. But aren't.

Metrics in software is a bag of issues in most companies I see. But there ARE useful ways to use metrics that actually help (software). I did a talk about this at GOTO: Lies, Damned lies, and metrics. https://www.youtube.com/watch?v=goihWvyqRow

I'd pay extra $5 per month for a better voice.

Where is the music being sourced from? As a music creator, how can I add my music to be visible here? Another question (which contradicts my first question): Aren't you helping to create another "race to the bottom" where free music always wins over paid?

Unit tests have a lot of value, in an overall testing strategy: https://pipelinedriven.org/article/a-pipeline-friendly-layer...

How would you deal with bad actors? Someone who just uploads the latest Adele album onto soundrat to enable it to be fully streamed for free?

Author here. It's literally the first line in the blog post. And it links to this blog post about static environments: https://pipelinedriven.org/article/the-four-biggest-issues-w...

That's a good way of putting it. In TOC terms, the build time becomes the new constraint to solve, but only after you solve the build frequency constraint.

True, but that type of optimization is quite moot if you're only running the build at night (i.e, that's not the first constraint to solve). In the article I mention that first get the builds to be tight one after another, then work on build times because that becomes the constraint.

That would be ideal, but many organizations don't yet have that capacity for large builds/deploys (yet).

I'd (and I think many audio pros) would pay for this as a VST plugin in my DAW to visualize things as a reference (like magic A/B or MCompare - put a reference track and switch visualizations between the two references).

The visualizations could be more details to show various frequencies or zoom in on specific areas etc..

Can I also recommend my book for software team leads to be included? "Elastic Leadership: Growing Self Organizing Teams" https://www.manning.com/books/elastic-leadership

What's really missing from the IT world is a good understanding of leading vs lagging indicators (metrics) - which would help remove many of the anti patterns we know are bad, but can't explain why. I talked about it in this at GOTO last year: https://www.youtube.com/watch?v=goihWvyqRow

"Notes to a Software Team Leader" - on Audible, is an older version of my print book "Elastic Leadership": https://www.audible.com/pd/Notes-to-a-Software-Team-Leader-A...

Roy here. If you have any questions about the upcoming edition let me know.

It's really about day to day decisions being "pipeline driven" - allowing automated pipelines to make continuous tactical decisions that humans usually make in "traditional" processes. When to merge, is it secure?, when to deploy, is it up? when to spin up an environment? when to rollback, when to enable a flag, when to declare "all OK" etc.

This also means, not just dev and ops skills. It's also testing, also security, also compliance. "pipeline driven" is what we are after. And this of course enables true continuous delivery.

"DevOps" is another Silo. Which is why we also have "DevSecOps" and "TesOps" etc...

I'm in the process of writing a new book about this new-old idea: https://leanpub.com/pipelinedriven/

I maintain a blog about tech leadership at 5whys.com (turned it into a book later on called "notes to a software team leader")

I see a lot of similarities between writing code and making music. I wrote about it here: https://osherove.com/blog?tag=codemusic

I came up with my own set of questions that hopefully show how a person can deal with human complexity at work (the bulk of our issues), rather than memorizing algorithms. Some people don't like it - but it works for me: https://www.5whys.com/articles/a-realistic-hackerrank-develo...

For a team that has low code quality - here's how I like to start my code review process. not everyone will like it, but I find it effective at growing people's skills: https://www.5whys.com/articles/step-4-start-doing-code-revie...