Live data from Hacker News

Brut: A New Web Framework for Ruby

naildrivin5.com

21–30 of 88 posts

Re: Brut: A New Web Framework for Ruby

#21
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…

People who try to enforce this stuff via license fundamentally misunderstand the nature of copyright law.

Do you plan to sue people to enforce your license? Do you think people who are committing war crimes / crimes against humanity are going to not violate your license alongside all their other crimes?

The only thing this license accomplishes is ensuring no even semi-serious business will touch this with a 10' pole because it's a completely bespoke license with no prior understanding by their legal counsel. But you can already basically do that via the AGPL, except that some companies who are well-meaning may actually still use it.

Re: Brut: A New Web Framework for Ruby

#22
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…

The mocking thing actually touches on another point of frustration for me. I think the design of Rails ends up causing people to reach for mocking way too often in order to test things. At a glance I think Brut should avoid a lot of this by having things just be plain old Ruby objects.

I have dealt with countless Rails projects where testing things conventionally was difficult or impossible so mocks/stubs had to be used everywhere (controllers are the worst offenders here). When you start digging in to what's actually being tested, you find that the tests express little more than "this method is written the way it's currently written" rather than actually testing behavior.

Good tests should do three important things: catch bugs early in development, prevent regressions, and allow refactoring. Overly-mocked tests not only end up doing none of these but often actively work against these goals. They can't catch bugs because they reaffirm the current implementation rather than testing behavior. They can't catch regressions because any change to the code necessitates a change to the test. And they actively inhibit refactoring for both of those reasons.

All that is to say that maybe having a less-convenient mocking system is maybe a good thing :)

Also, since you're here, I want to say it also looks like your design encourages avoiding one of my other huge issues with Rails. I hate that ActiveRecord conflates the ORM layer with domain logic. This causes an antipattern where consumers of records (usually controller methods) pierce all the way down into the database layer by using AR methods and attributes directly. While convenient, this makes doing database-layer changes excruciating since your table layout is implicitly depended upon by pieces everywhere throughout the stack.

Better is to do what it looks like you suggest here: there should be an ORM layer that just exposes the database structure, and then you should layer domain objects on top of that which expose higher-level methods for interacting with persisted objects. If you change the database, you only need to change the mid-level layer. None of its consumers need to care that the underlying table layout changed.

From what I can tell so far I am very excited about Brut.

Re: Brut: A New Web Framework for Ruby

#23
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…

People who try to enforce this stuff via license fundamentally misunderstand the nature of copyright law. Do you plan to sue people to enforce your license? Do you think people who are committing war crimes / crimes against humanity are going to not violate your license alongside all their other crimes? The only thing this license accomplishes is ensuring no even semi-serious business will touch this with a 10' pole…

I didn't come up with the license. You can read about it here: https://firstdonoharm.dev/

I didn't want the code to be All Rights Reserved, so I chose the best license I could find that communicates my desires - I assume that's what most people do when choosing a license?

I'm OK if a "semi serious business" don't want to use my software.

Re: Brut: A New Web Framework for Ruby

#24
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…

Usually a signal of a personal/hobby project not to be taken seriously.

Re: Brut: A New Web Framework for Ruby

#25
post #22

Earlier quoted context omitted.

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…

The mocking thing actually touches on another point of frustration for me. I think the design of Rails ends up causing people to reach for mocking way too often in order to test things. At a glance I think Brut should avoid a lot of this by having things just be plain old Ruby objects. I have dealt with countless Rails projects where testing things conventionally was difficult or impossible so mocks/stubs had to be u…

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 :)

Re: Brut: A New Web Framework for Ruby

#26
post #20

[flagged]

All frameworks are like that. They make it simple to solve a particular class of problems, by making choices for you, and providing code that supports these choices. If your problems fit the framework's shape, it can be immensely helpful. If not, go look for another. There's nothing wrong about building a framework that matches your particular needs and tastes. If you need a universal toolbox, no framework will do, y…

One can learn a lot from the Adapter pattern. Don’t force me into your box, provide a framework for me to solve my problems.

Re: Brut: A New Web Framework for Ruby

#27
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…

[deleted]

Re: Brut: A New Web Framework for Ruby

#29
post #16

Earlier quoted context omitted.

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.

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…

Reading test failure output is much more readable and usable under RSpec vs. Minitest, to my eye.
Post reply on HN