> Shipping them 20MB of javascript before we even render a form would be a ridiculous thing to do.
> I have seen teams waste person-months of effort wrangling React validation libraries.
> It is not acceptable to bounce users on old browsers, users with bad network connections, users using assistive technologies.
> Build a web application that works on a playstation portable on a 3G connection - if you do, it will work for all your users, and it will still work 30 years from now.
The other day I added a fix so that the website would work in a PS5. Before that I didn’t even know that PS5 has a browser.
I love it! A few questions that made me think:
- how do you know that "people use it for all kinds of things"? I just read your privacy policy and I'm concerned about my AI agent possibly leaking some API key to Hutch and then you can read it.
- how is this free? You're hosting on Vercel, one of the most expensive hosting providers. What happens when this goes semi-viral? How do I know you won't just pull the plug to cut costs or start charging $500/month? I don't want to sign up, invest my time, and then lose access.
- I signed up and now I can't access privacy policy nor terms of service pages, because when I go to https://hutchdb.com/ I get redirected to https://hutchdb.com/dashboard
Censorship is not a solution. Instead, companies, whose messages are misleading, could pay a fine for their misleading message. Otherwise, you end up in 1984...sorry, I mistyped "UK in 2026".
You can even charge once a week or even less, depends on the usage.
You also don't have a gas station inside your apartment. Depending on which car you get, you could go charge it to charging station. I'm not saying this is instant process.
I'd love to hear more about this kind of attack being exploited in the wild. I understand it's theoretically possible, but...good luck! :)
You're guessing a cipher key by guessing typed characters with the only information being number of packets sent and the time they were sent at. Good luck. :)
I'm baffled about this "security feature". Besides from this only being relevant to timing keystrokes during the SSH session, not while typing the SSH password, I really don't understand how can someone eavesdrop on this? They'd have to have access to the client or server shell (root?) in order to be able to get the keystrokes typing speed. I've also never heard of keystroke typing speed hacking/guessing keystrokes. The odds are very low IMO to get that right.
I'd be much more scared of someone literally watching me type on my computer, where you can see/record the keys being pressed.
> For me personally, I have decided I will never be an Anthropic customer, because I refuse to do business with a company that takes its customers for granted.
Archaeologist.dev Made a Big Mistake
If guided by this morality column, Archaeologist should immediately stop using pretty-much anything they are using in their life. There's no company today that doesn't have their hands dirty. The life is a dance between choosing the least bad option, not radically cutting off any sight of "bad".
> How much better would this library be if an expert team hand crafted it over the course of several months?
It's an interesting assumption that an expert team would build a better library. I'd change this question to: would an expert team build this library better?
I also prefer symbols as keys in hash. It just looks more aesthetically pleasing. :)
I think the optimization string vs symbol is negligent in most of the apps. If you need that level of optimization, you should probably switch to Rust.
> If I need to query a hash often, I tend to write a method, and the method then makes sure any input is either a string or a symbol for that given Hash.
This is terrible. This is the exact opposite of what Ruby is trying to achieve: developer happiness. You basically implement "symbol is a string" for hashes (aka HashWithIndifferentAccess).
> But it has. I still use "# frozen_string_literal: true", but if you omit it, the Strings are frozen by default.
This is not the case. If you omit "# frozen_string_literal: true", the strings are mutable, in all versions of Ruby, even in Ruby 4.0, which will be released on 25 Dec.
> But a Symbol is not a String. Not even an immutable String. I understand what you mean (and internally it may be that way already, actually), but it is not a String.
If it walks like a duck and quacks like a duck...
Who cares? What's the difference it makes for you whether symbols and string are interchangeable? Show me one valid use-case where having symbols and strings being different (user[:name] vs user["name"], or attr_reader "name") is useful.
user = { name: "Alice", age: 30 }
puts user[:name] # Alice
puts user["name"] # nil
I'm 100% convinced that every Ruby developer has at least once made a bug where they tried to access a hash entry using a symbol, where the key was actually a string or vice-versa.
It would be great if Ruby would finally have immutable strings by default and, at that point, it would be possible to make symbols be strings.
This would prevent any such user[:name] vs user["name"] bugs while not breaking any other functionality. And also keeping the memory "optimized" by reusing a single immutable string.
No one thinks they are a dick. But you are. At least in many instances as many of the comments here and elsewhere point out. I had similar experience trying to start a discussion about something in one of the Homebrew repositories.
The fact that you have many friends who confirm your bias of not being a dick...means exactly nothing. You have people telling you your words made them perceive your comment as being arrogant/blunt and your reply is: I'm successful open-source maintainer and have many friends who think I'm not arrogant and I only take critique from them. Have it your way. But in my eyes, you're being a dick. (Don't misinterpret this as my judgement of your engineering skills. I love Homebrew and it's an incredible feat. Congrats.)
The variable naming convention used here could be improved for clarity. I prefer appending `El` to variables that hold DOM elements, as it makes identifiers like `tableEl` clearer and helps avoid ambiguity between variables such as `table` and `row`. Also, the variable named `table` does _not_ actually represent a table element; it would be more accurate to name it `data` or `tableData` to better reflect its purpose.
You're right! Although I get faily far by using Bust-a-gem VS Code extension. (The underlying ripper-tags gem can work with any IDE)
https://github.com/gurgeous/bust-a-gem
I have an "on save" hook that runs ripper-tags on every file save. This keeps the definitions always up to date.
This sounds like a really innovative idea. I haven't seen a dedicated place for "collection of useful procs", but one emerging pattern is to use `app/services` and then have a bunch of single-responsibility service classes that each have call or perform method and then you use the service when you need some shared functionality. It's like a proc, but instead it's a class with `#call` method.
It's weird, and different and therefore a bit repulsive (at least to me it was) at first. But, once you learn it, it's so easy to read it and to understand what's going on.*
* Side-note: Sometimes variables or methods look the same as parenthesis () are optional. So, yes, there's more things that can look like magic or be interpreted in multiple ways, but more times than not, it helps to understand the code faster, because `clients` and `clients()` (variable or method) doesn't matter if all it does is "get clients" and you just need to assume what's stored/returned from that expression. Also "get clients" can be easily memoized in the method implementation so it gets as close as possible to being an actual variable.
- It might take time for your eyes to adjust.
- No matter how good the screen resolution is, you'll see pixelated reality rendered. Luckily Mac extended screen resolution is quite impressive and better than the live video of the room around you.
- Keep your eyes healthy, try to remember to take off the device often and go check your eye sight, especially after first few months.
- It might not work for you like it works for me (YMMV).
Oh, I didn't know that André wants to sell gem.coop and/or rv. Can you please point me to more info about where this intention to sell gem.coop and/or rv was mentioned?
They want to sell some RubyGems logs about corporations (not individuals) using RubyGems API, to...Ruby Central?
As André explained on his site, he was on-call at the time when they were removing him. He acted to protect the service by limiting access. No harmful actions done by him were ever discovered by Ruby Central. It's two entities fighting to remove the other. You can say Ruby Central was right, I can say André was right. But we do know that Ruby Central fired the first shot when they (could've been an actual hacker) removed literally everyone from RubyGems and Bundler projects.
> Shipping them 20MB of javascript before we even render a form would be a ridiculous thing to do.
> I have seen teams waste person-months of effort wrangling React validation libraries.
> It is not acceptable to bounce users on old browsers, users with bad network connections, users using assistive technologies.
> Build a web application that works on a playstation portable on a 3G connection - if you do, it will work for all your users, and it will still work 30 years from now.
The other day I added a fix so that the website would work in a PS5. Before that I didn’t even know that PS5 has a browser.