I love this! It sounds exactly what I’d want to use for a side project or a project with a limited number of reasonable, senior coworkers.
You can run the site locally, or view pages on the site by going to https://brutrb.com/adrs.html and clicking those links.
For your personal hobby project, go nuts. Break all the rules and cowboy all your own conventions.
But for business applications, the conventions Rails enforces at least make codebases somewhat familiar if you've seen a Rails codebase before.
At a certain codebase size, boilerplate is almost unavoidable. Unpleasant, but necessary. Personally, I'd rather have some conventions, rules, and guardrails for where the boilerplate lives rather than trying to navigate your homegrown pile of code. Good luck maintaining that spaghetti when you've got multiple developers.
It's not clear how this new web framework avoids boilerplate anyway, so I don't see how this is an improvement over Rails. Presumably you'll still need to set up lots of stuff yourself, like RSpec. If the framework sets all of that stuff up for you in a conventional way, then you're just back to square one as soon as you need to fight against the framework's conventions.
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!
Minitest (which is bundled with Ruby these days) is Good Enough™. It doesn't require you to learn a new DSL. Everything is just Plain Old Ruby. The use of RSpec these days—IMO—is just cargo-culting forward what was the right decision from 10+ years ago. Having an pseudo-English style interface for testing isn't worth having the additional dependencies nor the mental overhead of needing to know how the RSpec syntax is actually mapped into Ruby concepts.
I'm not asking you to change it, you're welcome to have a different opinion than mine. But I am curious if you have strong reasons for requiring it. Particularly because MiniTest seems to be well-aligned with the rest of your design philosophies, unlike RSpec.
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 having to monkeypatch the world.
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 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.
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 :)
* 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 of the Taliban;
* 3.1.13. Myanmar: Be an individual or entity that:
* 3.1.13.1. engages in any commercial transactions with the
Myanmar/Burmese military junta; or
* 3.1.13.2. is a representative, agent, affiliate, successor, attorney, or
assign of the Myanmar/Burmese government;
* 3.1.14. Xinjiang Uygur Autonomous Region: Be an individual or entity, or a
representative, agent, affiliate, successor, attorney, or assign of any
individual or entity, that does business in, purchases goods from, or
otherwise benefits from goods produced in the Xinjiang Uygur Autonomous
Region of China;
[...] * 3.2. The Licensee SHALL:
* 3.2.1. Provide equal pay for equal work where the performance of such work
requires equal skill, effort, and responsibility, and which are performed
under similar working conditions, except where such payment is made
pursuant to:
* 3.2.1.1. A seniority system;
* 3.2.1.2. A merit system;
* 3.2.1.3. A system which measures earnings by quantity or quality of
production; or
* 3.2.1.4. A differential based on any other factor other than sex, gender,
sexual orientation, race, ethnicity, nationality, religion, caste, age,
medical disability or impairment, and/or any other like circumstances
(See 29 U.S.C.A. § 206(d)(1); Article 23, United Nations Universal
Declaration of Human Rights; Article 7, International Covenant on
Economic, Social and Cultural Rights; Article 26, International Covenant
on Civil and Political Rights); and
* 3.2.2. Allow for reasonable limitation of working hours and periodic
holidays with pay (See Article 24, United Nations Universal Declaration of
Human Rights; Article 7, International Covenant on Economic, Social and
Cultural Rights).
[1] https://firstdonoharm.dev/version/3/0/cl-eco-media-my-tal-xu...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.
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.
Hm, uh, seems like now we will be forever asking ourselves this question about /widgets.
That being said, it looks good! Might get me back into ruby if I can come up with a project for it.
freedomben•3h ago
Looking forward to trying it out!