HN user
There’s also a typography element to formatting source code. The notion that all code formatting is mere personal preference isn’t true. Formatting code a certain way can help to communicate meaning and structure. This is lost when the minimal tokens are serialized and re-constituted using an automated tool.
https://naildrivin5.com/blog/2013/05/17/source-code-typograp...
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 :)
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.
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!
Author here - the example doesn't allow logins now to avoid abuse. I wasn't 100% sure I'd make it public and just decided today to do it, so it's not yet ready for just anyone to login.
You can run the site locally, or view pages on the site by going to https://brutrb.com/adrs.html and clicking those links.
This is my favorite game for the 2600.
I built a clone of it for Windows using Direct X in probably 1999/2000. I don't have a Windows machine, but I think Microsoft's obsession with backward compatibility means it probably still works:
https://naildrivin5.com/adventure/index.html
Here's the C++ code in all its glory: https://github.com/davetron5000/adventureclone/
It replicates the 2600 game, and adds two new levels (additional castle and maze), and two new (optional) objects, a candle that shows more of the labyrinths, and a shield that prevents the dragons from eating you.
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.
I built one recently. Much simpler and more opinionated, but can generate a Tailwind configuration: https://ghola.dev (desktop/ipad is best)
Long read on how it was built with web components: https://www.naildrivin5.com/blog/2024/01/24/web-components-i...
I loved U1-4 on the C64. If you like this sort of thing I created an ultima-inspired in browser game https://starlightdawn.online
It’s an interactive story and not a CRPG but there is a goal.
Web Components are not a replacement for React. They are a thing you would use to build React if you were to do so today. To use only Web Components, you will be writing a lot of low-level code using the browser's API, or you will have to use a framework built on Web Components
To save anyone a click, the author figured that AirBnB's urls had monotonically increasing numeric ids, which is the Rails default, and figured out that the AirBnB CEO's id was 3, and got the direct link before it was shared publicly.
Based on how it is implemented, it probably should've been called `trace` because it is one level below debug.
I dunno, the OP may want to work with a processor that provides transparent and clear customer service.
Their engineers need promotions so how else can they get them?
The typography is almost great but it full justifies all text (at least on mobile) which looks horrible. Web browsers have limited hyphenation and don’t do any kerning or other adjustments (like hyphenation) to make full justified text look good like it does in a book.
These almost entirely boil down to DHH's personal preferences—which is fair enough as it's his framework—but I don't really see these helping in any general way to understand Rails beyond "whatever DHH wants is his framework".
If you want to understand the core values of Rails they are:
* Implicit behavior through conventions regarding core features like databases and routing * The framework has a reasonable built-in for anything you'd need to make a web app * Major new features or changes usually originate from DHH and 37 Signals
The stated values are mostly useless:
* Programmer happiness - completely subjective as to who is being made happy. Lots of Rails things make lots of people unhappy just as much as the opposite.
* Convention over Configuration - this is the only clearly stated value and it is basically the core ethos of Rails, even though it really means "as compared to J2EE". Rails has a TON of configuration you still need to do on any project.
* The menu is omakase - the text explains better, but the point is that everyone should use the selected tools and yet a good chunk of Rails developers deviate from stuff like minitest, fixtures, etc. That the defaults can be swapped out was never a goal of DHH's and I think they exist only because of the merge with Merb way back when.
* No one paradigm - this is just a retcon for how different parts of rails are different from no really good reason. Why are helpers a big blob of global functions? Why does a controller expose data to the view via instance variables? Why do schema migrations default to nullable fields and no foreign key constraints? Why do you define instance methods on mailers but invoke them as class methods? There's no rhyme or reason to this. It's not bad, but it's also not the result of deeply thinking about the best way to approach these problems.
* Exalt Beautiful code - DHH sets the standard of beauty. This is possibly the worst part of the doctrine because when others adopt this it leads to constant infighting about style and other pointless things. If you've ever seen any of Basecamp's code online, I would not personally call it beautiful. As a doctrine for an open-source project this is useless.
* Provide sharp knives - this is a curious one both in text and analogy. What he's saying is that "dangerous" features should be OK because people should be trusted to use them. Fine, I guess, but if you do any home cooking, sharp knives are far more safe than dull knives. And any language feature can be abused. What is very frustrating about Rails is these "sharp knives" tend to be unobservable so it's hard to know what is happening and why.
* Value integrated systems - this is where it is either DHH's lack of experience or just flat out delusion, because Rails provides exactly nothing to help scale a monolithic system to hundreds or thousands of developers and tons of performance requirements. It can be done - look at Shopify and GitHub - but nothing about Rails gives you a leg up on what is required to build a monolithic system. THAT SAID, like configuration over convention, this does demonstrate Rails value in a roundabout way - you get mostly what you need in one package and, unlike the JS ecosystem, don't have to piece it together on your with starter packs and boilerplates
* Progress over stability - Maybe initially this rang true, but Rails has been extremely stable for a long time, and that's a good thing. The team does a great job of deprecating things and providing an upgrade path, and Rails happy path features very rarely break between versions. But what progress has Rails made at a high level? It still works more or less as it did when it came out. This is totally fine and should be heavily promoted as an alternative to the constant change, rot, and churn in the JS ecosystem.
* Push up a big tent - this is almost entirely untrue. DHH does not value this. Maybe he did when this was written, but he does not value diversity on any real level, at least not based on his written words and public actions. This includes "diversity of thought" as well as "diversity of people".
The Doctrine is a nice idea, but I don't see how it helps anyone really understand Rails beyond "DHH's framework". And again, that's fine. It's his framework. He doesn't have to explain himself and, to be honest, I kinda wish he wouldn't.
There is no one who is eg the GM of Heroku. Salesforce has no idea what they have and are basically tying to figure out how to get existing SF customers to use it. I think they want Heroku customers to start using SF more but have no clue how. The result is that Heroku feels abandoned and on life support.
Its too bad because Heroku is a great product that has a ton more potential.
Unfortunately, I don't have any demographics on who orders from me. I only ask for an email address. Mostly have just tried to minimize access to personal information.
I have had several readers over the last year reach out to ask about this. I ended up adjusting the pricing in Amazon per region (print copies) and creating discount codes for people to use on my site based on the honor system[1]. For books I sell through Pragmatic Programmers, they did not have a way to adjust the pricing per region.
For me, the goal is reach and not profitability. The reality of selling technical books is that you can’t make a living on it, so it's really a "loss leader" on my employability.
In the past six months:
• 390 total orders
• 116 used one of my PPP discount codes
• Mexico's code is the most used, followed by India, then Europe. Mexico and India offer the steepest discount, though Europe's is not particularly steep, so I don't think anyone is gaming the system. Note that the amount of discount is not published until you apply the code at checkout.
For pricing an app or other thing where economics were more important, I might still do it, and factor it into the business model, basically eating some AOV to get growth/TAM.
SOLID is going to be problematic and it’s easier to focus on baser things like cohesion and writing simple, unabstracted code.
https://solid-is-not-solid.com has a snarky take on this but I wrote it to be apt as well.
I was the third engineer hired at Stitch Fix, and Ruby and Rails has been a key part of our success as an engineering team. We spent the first 12 months delivering value and keeping up with the business. We didn't spend time dealing with tool selection, choosing plumbing options, or any of that and it was key in establishing our team as a partner in the business (as opposed to just being the IT shop). I can't imagine a startup using anything else(), especially early on. While we may replace parts of our code with more specialized tools, Ruby and Rails will continue delivering value for quite some time.
() certainly if your domain is something specialized, this statement makes no sense.
We use both and RabbitMQ is not a solution for this problem. Message handlers/listeners are equally susceptible to this problem on Heroku (or, generally, to being killed).
RabbitMQ can be configured to not ack messages where an exception was raised, so if you have a durable store and the code responding to messages is idempotent/retriable ,you are good to go. Such a system can be easily configured with resque jobs using resque-retry, so it's mostly down to how you design your jobs/listeners/message handlers and not the underlying tech