mfonda

An “array” in PHP is an ordered map.

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?

I never knew that jq without any arguments pretty-printed JSON. Very useful, and great tip to combine with pbcopy/pbpaste.

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.

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

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.

Autoloading is pretty simple. PHP knows exactly where to look for code, and you know exactly where to look for it too. Class names are mapped exactly to file names [1], so autoloading lets you simply use a class without needing to explicitly include the file.

There's a number of issues inherent in manual include statements:

- When you include a file, unless you include it using the absolute path, the path will be resolved using the include_path ini setting, which works just like the $PATH environment variable works to resolve the location of binaries. Typically, `include_path` will be set to something like `/usr/share/php:.:/some/other/dir". If I encounter `require_once 'Foo/Bar.php';` in some code, what file will that include? `/usr/share/php/Foo/Bar.php`, but maybe also `./Foo/Bar.php`.

- Relative includes are relative to the current working directory, so a different file may be including (or not found at all) depending on what directory I'm executing my script from. To avoid this, it's good practice to include files using `include __DIR__ . '/Foo.php';` to ensure we know exactly what file is included.

- Prior to autoloading, most dependencies were installed in a global location, e.g. `/usr/share/php`, which would then be part of include_path. Different projects on the same machine therefore had to have the exact same dependencies. Autoloading enables per-project dependencies.

- Using manual includes makes it much easier to have a poorly structured project. With autoloading, if I see `$bar = new Foo\Bar();`, then I know exactly what I'm getting: the class Bar, defined in the file `src/Foo/Bar.php;`. On the other hand, if I see `include 'bar.php';`, I have no idea what I'm getting. What's in the file? Could be class, could be bunch of random functions, could be mish mash of HTML and PHP spaghetti.

Same of these issues are manageable even without autoloading by following best practices, but unfortunately there's a lot of really bad code out there that doesn't. Autoloading (along with composer) completely solves a problem that used to exist in PHP. Anyone that actually uses PHP can attest to this. If you've ever worked on a project with a web of manual includes, it's a total nightmare compared to a properly structured project using autoloading.

Autoloading aside, the point of this article, IMO, is that it's quite easy to set up a well structured, maintainable, easy to understand project architecture without using a major framework. The central abstraction here is that all requests go to a front-controller, which then calls a function that accepts a representation of the HTTP request and returns a representation of the response. Having abstractions for Request and Response is much more manageable (and testable!) than having random print statements everywhere and using global variables like $_POST. This is same idea behind just about all web programming "frameworks" in any language. Of course this would all be over kill if all you needed was a "Hello World" page. But this isn't about hello world pages, it's about real projects that grow over time and need manageable structure.

Furthermore, this article advocates for dependency injection. Again, overkill on a hello world page, but in a real project explicit dependencies makes life so much easier.

[1] This is the de-facto standard. Sure you could technically write an autoloader that does weird things, but nobody--human or automated tools--does this in real code. It's not a problem in practice--autoloading in the real world makes things much more explicit than manual includes.

The affected information included usernames, email addresses, and hashed passwords - the majority with the hashing function called bcrypt used to secure passwords.

If they're using bcrypt, then they're using salts since salts are built in to bcrypt.

There was no division of duties on the team. Everyone was responsible for the system as a whole. [...] Basically, I asked why he didn't take care of it. His response floored me.

"Oh, well, you always take care of it."

I've found that it's almost never the case that there is no division of duties. Sure, there may be no explicit division of duties, but there is almost always an implicit division of duties. If Person X is always the one that handles Task Y, then the team will come to view Task Y as a duty of Person X. Other team members may then just simply assume that Person X will take care of it, or they may even actively avoid it to avoid stepping on anyone's toes.

My DIY MacBook stand is simply a pile of old textbooks. Gets the job done and comes with the added bonus of adjustable height.

eNotes.com | Senior DevOps Engineer | Seattle, WA | Onsite

eNotes is an educational resource for both students and teachers. Perks include competitive pay, excellent benefits, and a great work-life balance with half-day Fridays.

We're seeking a Senior DevOps Engineer to improve and maintain our infrastructure. Ideal candidates should have extensive experience with AWS and be self starters able to identify areas that need to improvement and be able to effectively communicate with the dev team to make sure all needs are met.

If interested, please reach out to mfonda [at] enotes.com

Sorry about the lost videos, but that was a indeed a helpful comment. Any time you use any dependency, it's important to be aware of how it can change. Locking down a specific version, if possible, is generally a good route to take. Software in general, and especially SAAS, tends to change frequently, so building your project in an manner that safely handles changes is important.

The pitfalls of dependencies is something a lot of courses tend to ignore completely. Getting bit by dependency issues tends to be a hard-learned lesson, just like this one. Perhaps consider mentioning it in future classes.

Great post! Contents of it aside, I very much like the disclaimer:

In this post we’ll be discussing lots of ways to tune web servers and proxies. Please do not cargo-cult them. For the sake of the scientific method, apply them one-by-one, measure their effect, and decide whether they are indeed useful in your environment.

Far to often I see people apply ideas from posts they've read or talks they've seen without stopping to think whether or not it makes sense in the context they're applying it. Always think about context, and measure to make sure it actually works!

I'm a big fan of checklists as well; however, working through a checklist is still a manual process with room for human error. I've gone down the road of creating checklists, then realized that many of the items would be much better automated. For example, suppose a list item was "Ensure command X is called with arguments -a, -b, and -c, then command Y is called". This could all be wrapped into a simple script that calls these commands, eliminating the potential for human error. I've found that as I create checklists, they often turn into a list of things I really need to automate.

As an aside, I really like that they include the rationale with each item.

In addition to this, if a lot of the libraries you're using are written in PHP, it makes a ton of sense that command line scripts using those libraries would also be written in PHP.