Selfdogfood-fr

Ce contenu a démarré sur selfdogfood

Cet article est une ébauche. Vous pouvez aider le wiki IndieWebCamp à l'améliorer et le compléter.

Le selfdogfood est une forme spécifique de dogfooding, ce qui signifie, utiliser au jour le jour vos propres créations sur votre propre site personnel dont vous dépendez.

Métaphoriquement parlant, les idées d'une personne doivent être la construction dans laquelle il vit — autrement il y a quelque chose qui ne va vraiment pas. Søren Kierkegaard, introduction to Provocations

composants-clés

Le selfdogfooding a plusieurs composants requis, les deux premiers étant partagés avec le dogfooding :

• création active (que ce soit du code, UX, design interactif/visuel/graphique)
• utilisation de cette création (par votre société par ex.)
• utilisation personnelle de cette création - vous vous-même personnellement utilisant votre création pour vos propres usages personnels - et non pas juste une partie de votre travail quotidien quand vous terminez ou rentrez à la maison.
• self-identification/dépendance - utiliser votre création de toute manière qui vous représente, votre self, par ex. comme un constituant de votre identité primaire sur le web. L'acte de création enrichit un aspect du "self" public du créateur.

perspectives

• "Is its creator living and breathing it in his day-to-day online life? If so, awesome, if not, yawn." - Tantek 2013-01-03 11:05 (PST) (originally posted as a comment on a Google+ post).

• "no recent commits = evidence of absence of selfdogfooding = ignorable" - Tantek (2013-07-03 in IRC).

• If I make software for [someone else], am I ever going to rely on it? Unlikely
  If I make software which solves my own problems in a useful way, might others find it useful? Much more likely. - Barnaby Walters (2013-08-21 sur iRC)

• I have a higher tolerance for my own stupidly designed interfaces than [another person] would, but at some point I'm going to get frustrated by inefficiencies in my interface and make it better for me, which then makes it better for everyone. - Aaron Parecki (2013-08-21 sur IRC)

• ...

posts

Posts concernant le selfdogfooding (les plus récents en premier)

• http://upon2020.com/blog/2013/09/the-indieweb-community-has-it-nailed-selfdogfood/
• http://tantek.com/2010/200/t3/fsws-coders-challenge-use-your-code-publish-your-site

Discussion

• aucune en cours.

FAQ

Usage et développement

Y a-t-il deux dimensions au selfdogfooding : l’usage et le développement ?

R : Il existe beaucoup d’aspects obligatoires du selfdogfooding, l’usage et le développement n’étant que deux parmi tant d’autres.

Mises à jour de contenus mais sans commits

Est-ce qu’un site qui serait régulièrement mis à jour avec des posts mais sans avoir de commits durant un moment pourrait se qualifier sous l’appellation de selfdogfooding ?

R : À un certain stade, s’il n’y a pas de commits créatifs (code, UX, design) par l’utilisateur principal auto-identifié dudit site, alors il a migré du dogfooding (qui requiert une boucle de rétroaction création/utilisation) à devenir un simple utilisateur. Non, en fait, après « un moment », ceci ne devrait pas être considéré comme du selfdogfooding.

Commits invérifiables

Que penser des sites qui fonctionnent sur du logiciel non-open-source (pas moyen de vérifier directement les commits) ?

R : Même les sites web qui tourney sur du logiciel qui est soit un peu ou pas du tout open-sourcé peut encore être analysé pour les fonctionnalités qu’il utilise en termes de :

• apparence visuelle et interface-utilisateur
• notifications externes (par ex. PuSH et comportements webmention)

Par conséquent, même si des commits de code spécifique ne sont pas visibles de façon transparente, il existe plein d’autres sources directes et indirectes pour des modifications créatives (code, UX, design) et par conséquent, le jumelage création/utilisation peut être encore vérifié à un certain niveau.

Tester votre code en production

Même si tester votre code en production peut représenter une bonne partie du selfdogfooding, des précautions de sécurité devraient être prises. Afficher des erreurs, avertissements et notifications généralement réservés pour des environnements de dev représente un énorme risque de sécurité du fait que des choses comme les chemins, noms d’utilisateurs, clés secrètes, etc pourraient apparaître par inadvertance à quiconque s’y intéresse. Ce n’est pas du tout non plus une bonne idée que de présenter des messages d’erreurs avec le contenu.

Vous devriez plutôt ramener de tels messages à un endroit où vous seul puissiez les voir, ou ne les présenter tel quel dans la page que si vous êtes connecté en tant qu’admin.

En PHP, il y a plusieurs façons de faire ça.

• Désactiver les display_errors off dans votre php.ini
• Dans PHP: ini_set('display_errors', 'off');
• Pour une ligne unique @codeWhichIsCausingErrors();
• Si vous êtes connecté en admin :

  if ($user->isAdmin()) ini_set('display_errors', 'on');

voir aussi

• dogfood
• principes

<footer>source iwc:Selfdogfood-fr</footer>

<footer>