davetron5000

Thanks for the kind words!

(author here) It only uses Sinatra because I happened to know it and needed to bootstrap the low-level stuff. I don't know if it needs to be based on Sinatra in the long term - it should probably just use Rack.

I'm OK not using a compiler. Used one for years and am good on that for now. I like writing Ruby.

I like Ruby! Ruby has types. They just aren't enforced by a compiler.

Yeah, that makes sense. Where I end up wanting mocks is when this happens:

1 - build first version of feature, all core logic in a class I can test conventionally 2 - logic gets complex, test gets complex 3 - Eventually, I need to create some layering, where the class from step 1 now delegates to other classes. The initial test is more like an integration test and gets harder to keep up

At this point, there is a camp that says I should be using dependency injection and inject null objects for the dependencies. I get that idea. I am in the other camp that does not want to make custom objects just to satisfy a test. A mocking system can do that for me. So that's what I would do - mock the dependencies. The "real" versions would be tested conventionally.

I definitely do NOT just start with mocking imaginary internals though - I guess that's a whole other camp :)

The biggest thing is the mocking system. MiniTest's feels so difficult to use.

I also like creating custom matchers vs. creating my own assert_* methods.

I would agree that many features of RSpec are, honestly, bad: shared examples, shared contexts, etc. Excessive use of let! and let, plus the predicate matchers are all just really confusing to me.

I actually thought about patching the RSpec gem to remove the features I didn't like :) Might still consider it heh

I thought hard about this decision. Every time I use MiniTest, I end up wanting a bit more that RSpec has and then switching to it. I also have been surprised over the years that the `expect(x).to eq(y)` seems to be relatively intuitive to people, despite the fact that it doesn't seem like it ought to be.

Author here. The framework does require setting stuff up. RSpec is not one of those things. It's the testing library you will use if you use this framework. I didn't create a lot of flexibility in the framework. For example, if you don't like RSpec, you will not like this framework :)

You may want to examine the docs more closely. There are plenty of conventions and very few that can be circumvented.

But day one of a new framework is not going to compete with Rails. Sorry!

Where you live matters. In the US there is a significant tax burden on exercising. Talk to an accountant. Also look into QSBS which can shield your tax burden if the company was small enough when you were granted stocks. Highly recommend you get informed before talking to a professional. Not all accountants understand this stuff.

It wants to act on GitHub on my behalf. Not clear why I should allow it to do that, especially when the only info about this app that is presented is that it will store my data on GCP.

Can you modify your oauth request to only ask for what permissions you need and/or itemize out what the app is going to do on my behalf?

I built a toy app using this, with a front-end only app and postgrest + RBS. The app was seriously two forms behind a login. It was a huge pain.

RBS is "insecure by default" meaning if you don't set it up right, all users can access all data. And, because it's SQL, it's really easy to write a valid and successful configuration that doesn't work. You have to test it. And for views, you have to do some real heroics to get them to respect RBS.

PostGREST is very very basic and far less powerful than just writing SQL. I found it pretty frustrating to use, knowing that SQL would be far simpler.

Yes, I know that I could make a direct SQL connection to the database, but at that point, it would've been easier to put a Rails app on Heroku and use their offering, which is far more mature.

The Supabase dev environment was pretty slick and worked well, though I had to docker implode a couple times.

I wish them luck, but I could not figure out what the use case was for their product, given that Heroku has an awesome managed Postgres and RDS is there if you have more knowledge and want more controls. I don't see how you could make a complex app that is front-end only with Supabase as your entire back-end.