Modern PHP is great. Many powerful language features, excellent performance, great community and package ecosystem, and decent enough safety with modern static analysis tools.

I'm not too sure I agree with the author's complaints here. When using something like array_filter, you're typically mapping from collection to collection (i.e. you don't care about the first element--you care about the whole thing) and so this problem is really a non-issue. The next follow up step would usually be foreach, or another operation like array_map, in which case it's a non-issue.

If you really do need the first element, you can use array_first. And if you really do need a fixed-sized collection, you can use SplFixedArray.

The point on properties is valid to an extent, but IMO not really an issue you commonly run into in the real world (regardless of language, your constructors should generally return an object in a usable state).

Anyone else run into similar issues or have any tips?

As someone unfortunately prone to coming up with grand plans to build things, I could get a lot of use out of this. I have a handful of domains currently collecting dust, but hope to actually follow through on my plans at some point :) Far more time than I'd care to admit was spent on finding them, so something like this would have been a great time saver.

The most important feature IMO is the .com availability checking, which doesn't seem to be working at the moment. In addition to the AI-generated names, it might be nice to allow users to enter names manually as well (once I see an AI generated one, by brain starts to generate lots of similar ideas). Another cool feature could be to be able to select a domain you like, and then have it generate further suggestions similar to that name.

That said, I would need to see the prices come down before I'd consider using it. I see the Signature Shirt is $12. For comparison, I recently purchased 6-pack of blank t-shirts [1] for $21 ($3.50/shirt), and found them to be excellent quality. I've ordered similar packs in the past for similar prices, and have always received high quality products. It would be hard for me to justify spending 3-4x per shirt AND a $70 annual membership on top of that.

Without the membership fee I might consider it, but I think it's simply too expensive as it stands. I do think it's a great concept.

[1] https://www.amazon.com/gp/product/B086L1PM8V

It's inspiring to see you follow up like this and help out a wonderful mountain shop. A great reminder and inspiration to be more involved in my community.

Depending on the specifics of how it's handled, you may or may not need the actual error message. For example, in production you may want to implement some sort of logic (retry, display friendly error message, etc.), none of which needs the actual error message.

This feature isn't unique to PHP. Other languages with Exceptions, for example C# and C++, have this exact same feature.

Wow, I've been using :Ack for years and have always found that behavior rather annoying. I had no idea about :Ack! -- definitely going to remember this one.

Same results in Safari. Oddly enough, works as expected in Firefox.

It's certainly a mild annoyance when using someone else's computer, but in practice, seldom do I actually need to use someone else's computer, and even more seldom that I need to do development work on someone else's computer. It's usually helping someone out real quick, in which case it's easy enough to just deal with it. If I had to work on another machine for an extended period of time, it's easy enough to copy over my settings.

I've been using Dvorak for about seven years now, and personally I love it.

For the longest time, I typed on QWERTY using a glorified hunt-and-peck method. I could type decently fast, but speed aside, I knew that touch typing was something I needed to learn. Figure if I was going to learn, I might as well learn on Dvorak.

Extremely happy with that decision. Typing just feels natural now, and I can type fast enough. There's many people that type faster than I do -- both QWERTY and Dvorak -- but I don't think I've ever thought to myself "I really wish I could type faster."

The biggest challenge for me in learning Dvorak was after I had more or less "learned" the layout, there was a period where typing was still involved consciously thinking "move this finger to this key". Most of my mental effort at that point was spent thinking about where to move my fingers, which made it more difficult to think about the actual code I was writing. Moved past that phase after a few weeks and never looked back. Overall, it took about month to learn, and it wasn't too difficult.

The author also mentions challenges when using someone else's computer. For me that's been a mild annoyance at worst--not enough of an annoyance to be worth complaining about. And on Mac OS at least, it takes all of a few seconds to switch keyboard layouts.

My takeaway from "If you don't believe this, I suggest you carefully reexamine your assumptions." is "If you believe something is true, stop and think critically about _why_ you think it's true. Be open to the fact that this process may lead you discover it isn't true after all".

I don't ask brainteaser type questions, but I can see their appeal given the value of estimates. I also don't see why they're so universally hated. Is doing back-of-the-napkin math something a lot of people struggle with?

Overall, these look like a great set of standards to follow. A few items that I think deserve additional attention:

> Use a collective name or, less ideally, a plural form. For example (in order of preference) staff and employees.

I fully agree with using plural names. Plural makes a lot of sense IMO because tables contain multiple things. An employees table contains many employees.

However, I disagree with using the collective name. There is too much ambiguity: the collective name doesn't always exist, doesn't always mean the exact same thing, and there are often multiple options for the collective term. Simply converting it to plural by appending an s (if possible) makes things more consistent and easier to quickly see, and can furthermore help with things like automatically naming tables / deducing table names.

Often times code exists that represents a single row in a table (e.g. we might have an Employee class that represents a single employee). Singular here makes sense to me because it represents a single row. To then find the table corresponding to this class (or vis-versa), it's simply a matter of pluralizing. If our table was instead "staff", this would be harder to see at a glance.

I'm curious why they advocate collective names--having trouble thinking of any advantages to this. Does anyone have any arguments in favor of collective names?

> Where possible avoid simply using id as the primary identifier for the table.

This is one of the biggest things you can do for SQL readablitiy IMHO. It's so much easier to quickly see what's going on when columns aren't simply named "id". If I see a column called "userID", I can quickly figure out that it's a userID with much less context than I would need if all I saw was ID.

One additional rule I would add, and this is perhaps a bit controversial: always declare columns as NOT NULL if possible, using a sane "empty default value" such as an empty string or 0. If I wanted to find all users without a name, it's much easier to do "SELECT * FROM users WHERE name = ''". This won't match NULLs--if we don't declare NOT NULL, then we must do "SELECT * FROM users WHERE name='' OR NAME IS NULL". Easy to forget this--better to have the extra safety of NOT NULL to prevent mistakes like this. A good rule of thumb IMO is "declare columns as NOT NULL unless you specifically need to allow null".

Haskell aside, I think this is a fantastic point regardless of whatever it is you're learning. There's always so much more to learn and having this mindset makes it a lot easier to do so.

I'm arguing that this tip is harmful. I should know he was on vacation, and thus have a plan in place to handle anything that might come up while he's on vacation. If I'm completely in the dark about when he's working, things are going to be a lot more difficult.

Nothing against remote work, but knowing everyone's typical working hours makes things run a lot more smoothly.