After over two decades of working in PHP, I'm now working in Java. PHP is basically Java-lite. I am absolutely loving the compile-time safety of Java, but I dearly miss PHP's maps and arrays. In Java, the amount of verbosity for defining a map/list and operating on it is overwhelming.
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).
If the changes your command makes are strictly to a relational database, then `--dry-run` becomes quite easy to implement: just start a transaction and never commit it. This avoids polluting the entire command with `if dryRun` checks everywhere. I've found this to be a great approach.
Does anyone have any insights into how Google selects source material for AI overviews? I run an educational site with lots of excellent information, but it seems to have been passed over entirely for AI overviews. With these becoming an increasingly large part of search--and from the sound of it, now more so with Gemini 2.0--this has me a little worried.
Anyone else run into similar issues or have any tips?
This brings back memories. The first (and only) hardware project I've ever done is building a 4-controller multitap that connected via parallel port. It ended up working really well--lots of fun playing games on snes9x with friends.
Great idea. Thanks for sharing, and congrats on launching it!
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.
I'm exactly the target audience here--simple, blank (logo free) apparel is exactly what I like to wear.
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.
Thanks for investigating this and ultimately getting the fraudulent store taken down. I saw the same social media post regarding the fraudulent store and was surprised that a small local store was targeted with this kind of attack. A good mix of small stores and major corporations in the list. I wonder if they target the small stores because SEO is easier?
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.
This information is often communicated by the type of the exception itself. Maybe it timed out: TimeoutException. Maybe the connection was refused: ConnectionRefusedException. Maybe it returned 404: NotFoundException.
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.
> Note that :Ack will jump to the first result in the QuickFix list by default. If you dislike this, use :Ack!
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.
Just a heads up that it's not working as expected in Chrome. I loaded the page and got an IP that wasn't mine, then refreshed the page and got a different IP that still wasn't mine. Upon further investigation, both incorrect IPs appear to be owned by CloudFlare.
Same results in Safari. Oddly enough, works as expected in Firefox.
I have a pretty customized setup--Dvorak, caps-lock remapped to control, vim a custom vimrc and set of plugins I'm used to, etc.
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.
This article boils down to "Dvorak was difficult for me to learn therefore nobody should learn it."
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.
What I believe it's saying, and accurately so IMO, is there are a lot of so-called "best practices" which are dogmatically followed without stopping to critically think about whether or not they actually make sense in the context in which they're being applied.
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".
Being able to approximately estimate numbers is an excellent skill for software developers to have. Imagine you're running some operation that affects N things or has N results. After seeing the results, it's very helpful to ask yourself "Does N roughly match what my intuition/estimate told me it would be?" If your estimate is off by at least an order of magnitude, it's a hint there could be a bug in your solution and that it warrants a closer look.
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?
As with any style guide, many things are subjective, and the only correct answer is the one that your team applies consistently, whatever that may be.
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 is not an achievement to unlock or a trophy to be won because learning is a never-ending process and not a finish line.
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.
This was in response to Practical Tip #1: "People don't have to say when they are working."
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.
As true as this is, unexpected problems happen. Kevin may be the only one that can fix it, or at least be able to fix it a lot more effectively than others. The issue might not be Kevin's fault (i.e it's really a process problem), but being able to talk to him immediately (or at least know his schedule) will go a long ways in getting the issue resolved in an acceptable time frame.
Nothing against remote work, but knowing everyone's typical working hours makes things run a lot more smoothly.