Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Brut: A New Web Framework for Ruby

naildrivin5.com

Post reply on HN
Print view View original

61–70 of 88 posts

Re: Brut: A New Web Framework for Ruby

#61

Post by F3nd0 »

wavemode wrote: post #14
cosmojg wrote: post #12

Oh man, Brut's HIPPOCRATIC LICENSE[1] is interesting! Just excerpting bits of Section 3.1 and Section 3.2 for example: * 3.1. The Licensee SHALL NOT, whether directly or indirectly, through agents or assigns: [...] * 3.1.12. Taliban: Be an individual or entity that: * 3.1.12.1. engages in any commercial transactions with the Taliban; or * 3.1.12.2. is a representative, agent, affiliate, successor, attorney, or assign…

All lovely ideals, but sadly means the project is not actually open source (by the official definition). And not compatible with the GPL and similar copyleft.

And not free software, either. A shame. :/

Re: Brut: A New Web Framework for Ruby

#62

Post by entropie »

freedomben wrote: post #2

Neat, this looks like it might be a good middle ground between Sinatra (which I adore) on the barebones/low-level end and Rails (which I also adore for apps that need it, but simple apps really don't). Looking forward to trying it out!

For me the middleground is hanami but ill watch bruts developement closely.

Re: Brut: A New Web Framework for Ruby

#64

Post by stouset »

1123581321 wrote: post #59
stouset wrote: post #53

Earlier quoted context omitted.

> My opinion is, _my unit tests_ are to protect my code against unwanted changes. This is just about the most bizarre take on unit testing I've seen in my 25-year career. > If I have to rewrite a method, usually I rewrite all of its unit tests. If you have to rewrite your tests every time you rewrite a method, you are entirely defeating the point of testing. What value you get from tests that only assert that the cur…

You seem confused about what he was saying. I’m sure you are familiar with unit testing philosophy with your experience. Calling a function and expecting a response does test the behavior of the application, just at a lower level than a request- or multi-request level spec. When he says rewriting a method he is referring to changing the logic of it; a refactor leaves the tests unchanged. That shouldn’t have needed to…

Tests should not generally need to be rewritten unless you’re changing the externally-visible behavior API of a function or library (either the literal API, its effects, or its semantics).

If you’re changing the tests because you’ve changed the internal, non-externally-visible logic of your code, your tests are almost certainly providing you negative value.

Being able to refactor and re-run your existing test suite to ensure consistent behavior is possibly the important property of a good test suite.

Re: Brut: A New Web Framework for Ruby

#66

Post by [deleted] »

davetron5000 wrote: post #49
hamzakc wrote: post #42

I see it is currently based on Sinatra. Just wondering if you have considered looking into Roda?

(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.

[deleted]

Re: Brut: A New Web Framework for Ruby

#67

Post by lloeki »

davetron5000 wrote: post #17
stouset wrote: post #16

Earlier quoted context omitted.

Do you mind elaborating on what more you end up wishing you had? Most of the additional features RSpec adds seem worthwhile but just end up being more complicated/confusing in the end, in my experience. Shared contexts/examples, for example. Others like let blocks should… just be methods. I will say the change in… I think it was RSpec 3(?) to the expect(x) syntax was a hugely positive change, particularly in not havi…

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 feature…

> I actually thought about patching the RSpec gem to remove the features I didn't like

Hmm it all sounds like you'd end up bastardising Rspec into being Minitest::Spec?

If you really like things like `expect().to` it's much easier to add it to Minitest::Spec (I did it back then, since there's `_().should` it's like 5-10 lines) than removing all those features and suffering the rspec weight.

Post reply on HN