Nedomas

two weeks ago I started heavily using Codex (I have 20y+ dev xp).

At first I was very enthusiastic and thought Codex is helping me multiplex myself. But you actually spend so much time trying to explain Codex the most obvious things and it gets them wrong all the time in some kind of nuanced way that in the end you spend more time doing things via Codex than by hand.

So I also dialed back Codex usage and got back to doing many more things by hand again because its just so much faster and much more predictable time-wise.

We've built a version of this on steroids - not only a registry, but also one-click mcp hosting. Would love you eyeballs if you're into mcp: https://supermachine.ai

Welcome to MCP hosting space guys. We’ve also been hosting MCPs since early Feb in https://supermachine.ai and investing a lot into open-source (see https://github.com/supercorp-ai/supergateway and many others).

Guess there’s gonna be more competition haha (but don’t worry, I think our approaches are a bit different).

There's open source package that allows delaying providing credentials to MCP server to runtime / via MCP tool call: https://github.com/supercorp-ai/superargs

For hosted MCPs: https://supermachine.ai

Met the guys in sf, the concept is great, can we really build o1-type of models with this? Congratulations on the launch.

Met with the Humiris MoAI team in sf, they are onto something cool

Yeah, I do both in prod and in the lib. In the lib I even ported Anthropics streaming API to be OpenAI compatible. Will write the docs over the coming days if interested.

Assistants API use in prod used to suck because it would send full convo on each message. But last month they added an option to send truncted history so its no longer 2$ a pop thankfully. Also Grok, Haiku and Mistral is cheap

I do and built Assistants API compat layer for Groq and Anthropic: https://github.com/supercorp-ai/supercompat I’d argue that Assistants API DX > manual completions API.

Hi HN! Started working with more text models in PyTorch, experimented with LSTMs and found most of the tutorials terribly outdated. So figured out whats the most modern best practices there (until next version of torchtext comes) and wanted to share. Do anybody use LSTMs at work or are most of the people on BERTs?

Thanks for the feedback. I'll add it. What kind of brand is it? I couldn't quite get your message fully.

YOU NAZI! Thanks - fixed it and am feeling ashamed of it a bit :)

We love them. They got a few quirks but overall experience is beautiful. Say thanks to them from me!

Thank you! I was trying to work those out for you. The problem is that we are use Typeform and they are kind of semi-ready for mobiles.

Got any ideas on how to improve it?

Thanks for checking it out! Just fixed it.

Fixed with 1.1.0 release.

https://github.com/Nedomas/databound-rails/commit/04e28afaf0...

Thanks.

For other readers: the issue is being adressed at https://github.com/Nedomas/databound/issues/2

Thanks for asking, James.

Many Rails apps get/create/update database data on the Javascript side. Sometimes it is done using some kind of framework (Ember, Angular).

This is for the times you don't use a full fledged framework - think React or something similar.

Its benefit is that you don't have to set up routes, parsing/encoding for the data you send.

It lets you securely choose which parts of the model you want the Javascript to edit (permitted_columns).

It also works with Active Model Serializers (f.e. UserSerializer) - it lets you specify which attributes to send to the client.

It is as secure as you would do it yourself.

If possible, please hack the databound.me website and help me fix the holes if there are any.

Thanks!

This tool saves developers from doing monkey jobs. It tries to write a passing RSpec spec off the bat. It does fancy analysis to predict the values it could feed to the API of a class.

It all started with a belief that writing unit tests is a much more deterministic process than writing app code. And it still holds true.

Running it would LOCK the class API in tests as it is. So all we would have to do is writing code, locking it, writing more code, locking it too and so on.

I am very thankful that it got featured in the Ruby Weekly today and would bake a cake for the anyone who made it happen. Thanks

It all started with a belief that writing unit tests is a much more deterministic process than writing app code. And it still holds true.

Do you think its possible to build writer in such a way so we don't have to write tests anymore?

Running it would LOCK the class API in tests as it is. So all we would have to do is writing code, locking it, writing more code, locking it too and so on.