😋 selfdogfood is a stronger form of dogfooding, that is, using your own creations on your own personal site that you depend on, as an aspect of your primary online identity, day to day — if you're not willing to use your creation on your own primary personal website, why should anyone else use it on their primary personal website?
Metaphorically speaking, a person's ideas must be the building he lives in - otherwise there is something terribly wrong. Søren Kierkegaard, introduction to Provocations
Selfdogfooding has several required components, one of which is dogfooding, but the other is the essential self part of selfdogfooding:
Posts about selfdogfooding (most recent first)
It has come up in discussion several times that a more appealing term should be used. No consensus has been reached yet.
Please add IRC links and summarize discussion...
In the Star Wars mythology about lightsabers, you (a Jedi) have *only* one, that you are expected to have *built* it *yourself*, and that you *depend* on as an extension of your *self*.
Use and development
Are there two dimensions to selfdogfooding: use and development?
A: There are many required aspects of selfdogfooding, use and development only two of them.
Content updates but no commits
Would a site that is regularly updated with posts but not have commits for a while qualify as selfdogfooding?
A: At some point if there are no creative (code, UX, design) commits by the self-identified primary user of said site, then they've shifted from dogfooding (which requires a creation/use feedback loop) to simply being a user. No, eventually, after "a while", that should not be considered selfdogfooding.
What about sites that are running non-open-source software (no way to directly verify commits)?
A: Even web sites running software that is either little or not at all open sourced can still be analyzed for what features they use in terms of :
Thus even if specific code commits are not transparently visible, there are plenty of other direct and indirect sources of evidence for creative (code, UX, design) changes, and thus the create/use pairing can still be verified to some extent.
testing your code in production
Whilst testing your code in production is a good part of selfdogfooding, security precautions should still be taken. Showing errors, warnings and notices usually reserved for dev environments is a huge security risk due to the fact that things like paths, usernames, secret keys, etc. might be inadvertently shown to anyone who cares to look. It’s also not a great idea to have confusing error messages intermingled with content.
Rather, you should log all such messages somewhere where only you can see them, or only show them in-page if you’re logged in as an admin.
In PHP, there are several ways to go about this.