mfonda
For example, the recent-ish OpenAI Hugging Face breakout was widely reported as a rogue model escaping. But a model on its own can’t do anything—it’s the agent/harness that escaped. I think it’s an important distinction and I’m glad to see efforts attempting to clear it up.
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.
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.
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.
If they're using bcrypt, then they're using salts since salts are built in to bcrypt.
> "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.
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
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.
> 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!