La nourriture.

Notre pain, et en général, notre nourriture, n’ont jamais de sucre ajouté. Je veux dire, si j’ai du pain, et il a un goût sucré, je ne l’achète jamais plus. Le pain n’est pas censé être sucré.
Nous mangeons beaucoup moins d’aliments transformés.
Nos villes sont accessibles à pied. Je vis à Madrid, par exemple, et je n’ai même pas de voiture. Je suis à 15 min. à pied de mon travail. Je vais à pied pour acheter des provisions et généralement tout.
C’est une de mes bêtes de compagnie personnelles : que se passe-t-il avec la manie sans gluten que vous avez là-bas? Je veux dire, si vous êtes allergique (ce qui est une chose objective qui a son propre test), alors je peux comprendre… mais le reste? Le gluten est une protéine, et l’une des protéines les plus complètes que vous trouverez dans le monde végétal… et vous l’enlevez du pain ? Vous êtes fous ? J’aime généralement les pains avec autant de gluten que vous pouvez trouver; ils sont généralement plus aérés, la croûte est plus savoureuse, et est beaucoup plus sain. Il n’y a rien de tel qu’un produit naturel.

Et cela a plus de protéines (environ 15%) que de nombreux repas transformés que vous mangez.

5. Graisses. Si vous ne vous gavez pas de sucres, vous avez de la place pour manger des graisses saines. L’huile d’olive, la principale, mais aussi les graisses qui vont avec la viande et le poisson. De même, si vous ne vous gavez pas de sucres et d’amidons ajoutés dans les aliments transformés, vous pouvez manger plus d’amidons. Je mange des frites la plupart du temps; bien sûr, pas les surgelés : directement coupés de la pomme de terre, et frits dans une bonne huile d’olive. Les bons gras sont importants pour être en bonne santé, aider à augmenter la testostérone et bien d’autres choses; si vous évitez la merde hydrogénée des aliments transformés, vous avez de la place pour eux dans votre budget calorique.

6. Les boissons sucrées. Nous en avons, mais nous n’avons pas la même culture que vous. Nous en buvons parfois, mais généralement la version zéro. Ils sont aussi de la merde, mais au moins pas de la merde sucrée ; et nous ne les buvons pas si souvent.

Programmation.

J'ai aucune expérience de la programmation moi-même, mais voici ce que j’ai à dire.

Nous commençons tous quelque part, et vous êtes déjà allés plus loin que d’autres en faisant le premier pas.

Je suppose qu’on pourrait dire que j’ai ce qu’on pourrait appeler un « cadeau » en chant et en poésie, mais je préférerais simplement acquérir ces compétences à partir de zéro, car ce serait plus satisfaisant pour moi, personnellement.

Même si cela peut prendre un certain temps, rappelez-vous que vous serez probablement en mesure de faire quelque chose avec des compétences de programmation comme ces projets incroyables que vous voyez autour de vous.Shopbreizh.fr est programmé en HTML 5.

N’oubliez pas qu’un bon nombre d’entre eux ont probablement commencé comme vous, vous, l’avez fait.

Même si je sais que c’est beaucoup plus facile à dire qu’à faire, faites de votre mieux pour ne pas comparer vos propres progrès à ceux des autres. Vous pouvez aspirer à être comme eux, mais essayez de ne pas penser aux différences de compétences et de qualité.

Personnellement, je suis curieux de savoir ce qui vous a amené à vous lancer dans la programmation, et si vous avez une idée de ce que vous voulez faire avec ces compétences.

Applications de la Loi de Pareto.

La réponse à cette question est à la fois qu’il y a et n’est pas une telle chose. Il y a beaucoup de situations dans la vie et le travail où vous pouvez obtenir un modèle. Souvent, le nouveau format est d’environ 80% compréhensible, vous pouvez travailler sur l’autre 20% que vous allez.Comme la loi Pareto le décrit. Ce n’est pas vraiment le cas avec les exigences logicielles. Le format est d’une importance cruciale, mais le processus par lequel ils sont créés l’est tout autant.

Les exigences logicielles se situent dans une zone délicate entre la pensée commerciale et technique.Suivant l'esprit de shopbreizh.fr . Ils s’occupent d’un projet technique qui produit des résultats opérationnels et, selon la personne qui les rédige, ils peuvent tomber trop loin vers l’un ou l’autre camp. Un ensemble d’exigences techniquement écrites peut se concentrer trop sur les questions de mise en œuvre, comme la conception des données, et passer à côté des avantages réels de l’entreprise était après. À l’inverse, les spécifications écrites par des personnes non techniques peuvent être verbeuses, ambiguës et répétitives. Croyez-moi, j’en ai lu des centaines.

La tâche principale d’un document sur les exigences est de communiquer ce dont l’entreprise a besoin. Il faut que ce soit dit de façon concise et sans ambiguïté, mais il faut aussi que ce soit lisible, ce qui crée immédiatement un paradoxe. Comment ce document sec et rigoureux ne peut-il pas être si ennuyeux que l’auteur y renonce à mi-chemin, ou que le public s’y engouffre en le regardant ? Il y a une réponse, cher lecteur, et je vais la révéler, mais d’abord un peu plus de contexte.

Le document sur les exigences ne peut pas simplement être rédigé en s’asseyant et en dénichant une foule de détails sur la base d’une séance de conseil blanc avec la micro-entreprise et ses représentants des utilisateurs. Le processus de création d’un ensemble d’exigences lui-même contient une série d’itérations où les concepts précoces sont développés, affinés, remaniés, simplifiés et parfois jetés. Trop souvent, cette partie du processus se limite à la séance d’information initiale.

Après une recherche exhaustive où j’ai examiné de nombreux exemples et méthodologies différentes, il est devenu évident que décrire les fonctions du logiciel comme un ensemble d’histoires avec un type défini d’utilisateur effectuant les actions était facilement le plus efficace. Je ne parle pas de la « user story » qui est utilisée par les équipes agiles pour mener à bien le développement, mais plutôt des « user flows » axés sur les objectifs qui peuvent être utilisés pour discuter des fonctions des logiciels qui n’existent pas encore.

Il est probable que l’équipe de développement pour laquelle vous recueillez ces exigences travaillera de façon agile. Créer un document monolithique « SRS » en une seule étape et le jeter par-dessus le mur à l’équipe de développement ne fonctionnera pas. Vous avez vraiment besoin d’un processus qui permette aux décisions prises au cours de la mise en œuvre technique d’être réintégrées de façon transparente dans le modèle. De cette façon, le prochain sprint de développement peut être basé sur les bonnes informations.

Si vous reconnaissez tous ces problèmes et désirez ardemment la solution, je vous recommande de jeter un coup d’œil à Primary. Il s’agit d’un système qui fournit les outils nécessaires pour créer des exigences complètes et non ambiguës que les utilisateurs opérationnels comprennent et que les utilisateurs techniques peuvent créer.